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ABSTRACT 


Organizations  of  all  types  are  becoming  increasingly 
dependent  on  the  operation  of  database  management  systems 
based  on  one  of  the  three  generally  known  data  models 
(i.e.,  network,  hierarchical ,  or  relational)  for  the 
centralized  control  of  operational  data.  As  an  alternative 
to  the  development  of  separate,  stand-alone  systems  for 
specific  models,  recent  research  has  proposed  a  system 
designed  to  support  multiple  data  models  and  model-based 
languages  as  if  the  system  is  a  heterogeneous  collection  of 
database  systems.  This  proposal  is  based  on  the  existence 
of  a  simple  and  powerful  data  model  to  which  the  three  well- 
known  models  can  be  mapped.  This  model,  the  attribute-based 
data  model,  is  the  data  model  upon  which  the  Mul t i -Backend 
Database  System  (MDBS),  a  software  database  machine,  is 
based.  This  thesis  concentrates  on  the  language  interface 
aspects  of  implementing  MDBS  as  a  kernel  for  the  support  of 
relational  databases.  In  particular,  this  thesis  provides 
the  design  and  analysis  of  an  interface  between  the 
relational  query  language  (SQL)  and  the  attr i bute-based  data 


language  (ABDL) . 
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I. 


INTRODUCTION 


Database  technology  is  rapidly  becoming  an  extremely 
important  aspect  of  data  processing.  Commercial  database 
management  systems  have  only  been  available  since  the 
1960's.  Today,  many  thousands  of  organi z at 1 ons  (e.g., 
corporations,  universities,  governments)  are  critically 
dependent  on  the  efficient  and  reliable  operation  of  these 
systems.  Each  of  these  organizations  has  invested  large 
amounts  of  time,  energy,  and  money  to  ensure  that  the 
various  end  users  are  provided  the  data  they  need  for  doing 
their  jobs  as  effectively  and  efficiently  as  possible.  Any 
of  the  three  generally  known  approaches  to  the  design  of 
database  systems  (i.e.,  network,  hierarchical  ,  and 
relational)  provides  for  the  centralized  control  of  an 
organization's  operational  data.  However,  questions 
concerning  the  ease  of  understanding,  use,  and 
implementation  have  stimulated  research  to  determine  the 
"best"  approach.  The  earliest  database  systems  were  based 
on  the  network  or  the  hierarchice.1  model.  These  models  lend 
themselves  well  to  the  efficient  implementation  necessary 
for  the  maintenance  of  large  databases.  Today,  with  the 
increased  emphasis  on  the  ease  of  use  and  understanding, 
many  of  the  newer  commercialized  systems  are  based  on  the 
relational  model.  Examples  of  commercially  available 


systems  based  on  these  models  include:  IMS  (hierarchical) , 
SQL/DS  (relational),  and  IDMS  (network).  Each  of  these 
systems  utilizes  a  model— based  data  language  which  allows 
the  user  to  specify  the  operations  to  be  performed  on  the 
data. 

Once  a  commitment  is  made  to  manage  a  large  database 
containing  an  organization's  operational  data  through  the 
implementation  of  one  of  these  systems,  it  is  financially 
prohibitive  to  change  to  another  approach.  In  addition  to 
the  obvious  re— programming  requirement,  user  personnel 
(including  high-level  executive  users)  must  be  re— trained  in 
the  syntax  and  semantics  of  a  different  data  language. 
Demur jian,  et.  al . ,  have  proposed  an  attractive  alternative 
to  the  development  of  separate,  stand-alone  systems  for 
specific  models.  Their  research ,  reported  in  CRef.  13, 
proposes  that  a  system  can  be  designed  "...to  support 
multiple  data  models  and  model -based  languages  as  if  the 
system  is  a  heterogeneous  collection  of  database  systems." 

The  above  proposal  is  based  on  the  existence  of  a  simple 
and  powerful  data  model  to  which  the  network,  hierarchical , 
and  relational  models  can  be  mapped.  This  is  the  attribute- 
based  data  model  as  originally  described  by  Hsiao  CRef.  23 
and  extended  by  Wong  CRef.  33.  This  is  the  data  model  of 
the  Mul ti -backend  Database  System  (MDBS),  a  software 
database  system  designed  by  Menon  and  Hsiao  CRef.  43. 
The  proposal  of  CRef.  13  is  that  the  attri bute— based  system 


(MDBS),  with  the  attribute— based  data  model  and  the 
attribute-based  data  language  (ABDL) ,  can  serva  as  a  kernel 
for  the  support  of  several  data  models  and  the  data 
languages  based  on  those  models. 

The  attribute-based  system  is  ideally  suited  to  its 
proposed  role  as  a  kernel  of  database  systems.  As 
demonstrated  by  Banerjee  CRefs.  5,  6,  and  73,  a  relational , 
hierarchical ,  or  network  database  can  be  converted  into  an 
attribute— based  database.  The  primary  database  and 
aggregate  operations,  RETRIEVE,  INSERT,  DELETE,  UPDATE,  MIN, 
MAX,  SUM,  COUNT,  and  AVG  are  supported  by  the  system's  high- 
level  data  language,  ABDL.  Finally,  language  interfaces  can 
be  developed  to  translate  relational,  hierarchical ,  or 
network  data  language  constructs  into  ABDL  constructs.  In 
this  thesis,  we  are  concerned  with  the  language  interface 
aspects  of  this  research. 

In  particular,  this  thesis  provides  the  design  and 
analysis  of  a  relational  interface  to  the  attribute-based 
system  (MDBS).  We  extend  the  work  of  Macy  CRef.  B3,  who  has 
shown  that  a  subset  of  the  relational  model— based  data 
language,  SQL  (Structured  Query  Language)  can  be  directly 
supported  by  MDBS  and  ABDL.  Macy  has  provided  mappings  from 
the  SQL  SELECT,  INSERT,  DELETE,  and  UPDATE  constructs  to  the 
corresponding  ABDL  constructs:  RETRIEVE,  INSERT,  DELETE, 
and  UPDATE.  The  translations  are  .limited  to  queries 
involving  simple,  single-relation  operations.  Using  these 


basic  mappings  as  a  -foundation,  we  show  that  SQL  queries 
involving  set  membership  operations  can  also  be  mapped 
directly  to  ABDL  constructs.  We  also  demonstrate  that  other 
SQL  constructs  (o-f  particular  importance,  the  nested  SQL 
SELECT)  can  be  mapped  to  a  series  of  ABDL  operations. 
Finally,  we  propose  a  software  structure  to  facilitate  the 
implementation  of  a  complete  relational  interface  for  the 
attr i bute-based  kernel  (i.e. ,  MDBS).  In  the  following  two 
sections,  we  discuss  our  design  goals  and  our  unconventional 
approach  to  the  design  of  the  SQL  interface.  In  the  last 
section  of  this  chapter,  the  organization  of  the  thesis  is 
presented. 

A.  DESIGN  GOALS 

We  are  motivated  to  design  a  SQL  interface  to  MDBS  in 
order  to  demonstrate  the  feasibility  of  utilizing  the 
attribute-based  system  as  the  kernel  of  database  systems  in 
general.  However,  our  intention  is  not  to  propose  changes 
to  MDBS  itself.  Instead,  we  propose  that  the  SQL  interface 
be  implemented  on  the  host  computer.  All  translations  are 
accomplished  in  the  SQL  interface.  MDBS  continues  to 
receive  and  process  requests  written  in  the  syntax  of  ABDL. 

Related  to  the  goal  of  avoiding  modifications  to  the 
functionality  of  MDBS  is  the  goal  of  keeping  the  syntax  of 
ABDL  intact.  We  utilize  existing  ABDL  constructs  in  our 
query  translations.  A  single  SQL  query  may  map  to  one  ABDL 
request  or  a  series  of  ABDL  requests.  The  processing  of  one 


request  may  depend  on  the  results  of  some  other  request  in 


the  series.  Clearly,  the  interface  must  include  some  method 
of  controlling  the  iterative  processing  of  series  of 
requests.  The  software  structure  of  our  proposed  interface 
(described  in  Chapter  VI  and  augmented  in  Chapter  VII) 
provides  for  this  iterative  control . 

As  discussed  above,  we  have  made  it  our  goal  to  leave 
MDBS  and  ABDL  unchanged.  We  also  desire  to  make  our 
interface  transparent  to  the  SQL  user.  For  example,  in  a 
corporate  environment,  a  new  employee  with  previous 
experience  with  SQL/DS  should  be  able  to  log  in  at  a  system 
terminal,  input  a  SQL  request,  and  receive  result  data  in  a 
relational  format  (i.e. ,  a  table).  The  employee  requires  no 
training  in  MDBS  or  ABDL  procedures  prior  to  utilizing  the 
system.  An  obvious  advantage  is  that  the  new  employee 
becomes  a  contributing  member  of  the  organization  almost 
immediately,  with  no  retraining.  The  non-productive  period 
of  new  employee  indoctrination  is  greatly  reduced. 

B.  APPROACH  TO  DESIGN 

Our  approach  to  the  design  and  analysis  of  a  SQL 
interface  to  MDBS  is  unconventional  by  today's  standards. 
The  normal  method  is  to  design  a  system  in  a  top-down 
manner.  High-level  abstractions  are  considered  first,  while 
deferring  lower— level  details.  In  this  thesis,  we  consider 
the  lowest  levels  first.  We  are  building  upon  the  basic 
subset  of  SQL-to-ABDL  mappings  provided  by  Macy  CRef.  83. 
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As  additional  SQL  operations  are  incorporated  into 
the  interface,  we  make  appropriate  additions  to  the  set  of 
SQL-to— ABDL  mappings.  The  functional  requirements  of  an 
overall  software  structure  for  the  interface  become  apparent 
in  Chapter  V,  when  we  present  ABDL  translations  for  the 
nested  SQL  SELECT.  The  functionality  and  organization  of 
structure  components  is  described  graphically,  in  text,  and 
through  the  presentation  of  high-level  algorithms.  We 
reiterate  that,  in  the  development  of  the  SQL  interface, 
MDBS  is  considered  to  be  a  "black  box”  which  processes 
database  requests  presented  in  the  syntax  of  ABDL.  We  are 
proposing  an  interface,  residing  on  a  host  computer,  which 
enables  a  user  to  access  a  relational  database  implemented 
on  an  attr i bute-based  system.  Recommendations  for 

[  modification  within  the  structure  of  MDBS  are  made  only  if  a 

desirable  SQL  operation  cannot  be  supported  by  existing  ABDL 
operations. 

|  Our  approach  to  the  presentation  of  SQL-to-ABDL  mappings 

is  as  follows.  We  first  review  the  direct  mappings  (i.e., 
SELECT/RETRIEVE,  INSERT/INSERT,  DELETE/DELETE,  and 

|  UPDATE /UPDATE)  developed  by  Macy  CRef .  83.  Beginning  in 

Chapter  IV,  we  investigate  additional  operations  to  be 
supported  by  the  interface.  The  f unct i onal i ty  of  each  of 
|  these  operations  is  thoroughly  explained  through  the  use  of 

example  queries.  The  equivalent  ABDL  requests  are  then 


determi ned 


All  examples  on  database  operations  presented  in  this 
thesis  are  based  on  the  Suppl i ers-and-Parts  database 
depicted  in  Date  [Ref.  91.  This  database  contains  three 
relations:  "S"  (Suppliers),  “SP"  (Shipments),  and  "P" 
(Parts) .  We  use  many  of  Date's  examples  directly  because 
they  are  well-known,  thereby  facilitating  reader 
understanding  of  our  SQL  to  ABDL  translations.  The  database 
is  depicted  in  Figure  1. 

C.  ORGANIZATION  OF  THE  THESIS 

In  Chapter  II,  we  present  an  overview  of  the 
organization  and  functionality  of  the  Mul ti -backend  Database 
System  (MDBS).  Also  presented  are  descriptions  of  the 
attribute-based  data  language  (ABDL)  and  the  relational  data 
language  (SQL).  Chapter  III  reviews  the  direct  SQL-to- 
ABDL  mappings  as  developed  by  Macy  [Ref.  81.  SQL  set 
membership  operations  involving  single  relations,  and  the 
equivalent  ABDL  requests  are  explained  in  Chapter  IV. 
Chapter  V  explains  set  membership  operations  on  multiple 
relations  (i.e.,  nested  SELECT).  In  Chapter  VI,  a  software 
structure  is  proposed  to  facilitate  the  implementation  of 
nested  SELECTS.  In  Chapter  VII,  the  interface  software 
structure  is  modified  to  include  the  functionality  necessary 
to  accomplish  the  translation  of  other  si ngl e— rel ati on  and 
mul t i pi e— rel at i on  operations.  Chapter  VIII  presents  our 
conclusions  and  recommendations  for  future  research. 
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II. 


THE  MULT I -BACKEND  DATABASE  SYSTEM  (MDBS) .  ITS  DATA 
LANGUAGE  ( ABDL)  AND  THE  INTERFACE  LANGUAGE  (SOL) 

As  we  begin  our  investigation  into  the  -feasibility  o-f 
designing  and  implementing  a  complete  relational  interface 
for  the  Mul ti -backend  Database  System  (MDBS),  it  is 
important  to  gain  a  general  familiarity  with  the 
organization  of  MDBS  and  with  the  system's  attr i bute— based 
data  language  (ABDL).  We  have  selected  the  Structured  Query 
Language  (SOL)  as  the  relational  data  language  to  be 
supported  by  our  interface.  Therefore,  we  must  also  have  an 
understanding  of  the  structure  and  capabilities  of  this 
1 anguage. 

In  Sections  A  and  B,  we  briefly  describe  MDBS  and  ABDL, 
respectively.  Section  C  provides  a  brief  description  of 
SOL.  These  descriptions,  though  somewhat  superficial, 
should  enable  the  reader  to  comfortably  follow  subsequent 
discussions.  A  complete  description  of  MDBS  and  ABDL  can  be 
found  in  Hsiao  [Refs.  4  and  103.  The  reader  is  referred  to 
Astrahan  [Ref.  113  and  Chamberlin  CRef.  123  for  in-depth 
discussions  of  SOL. 

A.  A  REVIEW  OF  THE  MULTI-BACKEND  DATABASE  SYSTEM  (MDBS) 

MDBS  is  a  multiple— mi i  i computer  backend  database 
computer .  Off-the-shelf  hardware  and  specialized  software 
are  combined  to  provide  database  management  service  to  a 


host  computer-  Figure  2  depicts  the  hardware  organization 
of  MDBS.  The  hardware  organization  includes  one 
minicomputer  as  a  controller  and  multiple  minicomputers  as 
backends.  Each  backend  has  one  or  more  dedicated  disk 
drives.  The  controller  and  the  backends  are  connected  by  a 
broadcast  bus.  The  database  is  distributed  across  the  disk 
drives  o-f  the  backend  in  such  a  manner  that  the  backends  can 
process  requests  in  parallel,  providing  a  significant 
performance  advantage  over  traditional  si ngl e-processor 
archi tectures. 

The  prototype  MDBS,  currently  operating  at  the  U.S. 
Naval  Postgraduate  School,  uses  a  VAX  11/780  as  the 
controller  and  two  PDP  11 /44s  as  the  backends.  Each  of 
these  backends  has  one  or  more  disk  drives  for  its  dedicated 
use.  The  multiple  backends  and  the  controller  are  connected 
by  DEC'S  Parallel  Communication  Links  (PCLs) .  Their 
broadcast  capabilities  are  simulated  in  software. 

The  major  design  goal  of  MDBS  is  to  provide  a  high- 
performance  system  for  1 arge-capaci ty  databases.  Throughput 
improvement  should  be  proportional  to  the  number  of 
backends,  and  the  response— time  reduction  should  be 
inversely  proportional  to  the  number  of  backends.  A  second 
design  goal  is  that  the  system  should  be  easily  extensible. 
The  system  should  be  able  to  accomodate  additional  backends 
with  no  modification  to  existing  software,  and  no  new 
programming.  The  incorporati on  of  additional  backends 
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Figure  2.  The  MDBS  Hardware  Organization 


should  not  require  modification  to  existing  hardware,  and 
disruption  of  system  activity  should  be  minimal.  The 
software  structure  of  MDBS  provides  this  extensibility.  The 
software  of  the  backends  is  identical,  utilizing  identical 
operating  software  for  the  additional  backends. 

It  is  clear  that  the  controller  could  become  a 
bottleneck.  MDBS  reduces  this  potential  by  minimizing  the 
role  of  the  controller  and  maximizing  the  amount  of  work 
done  by  the  backends.  The  software  structure  of  MDBS  is 
shown  in  Figure  3.  The  functions  of  the  controller  are 
limited  to  request  preparation,  insert  information 
generation,  and  post  processing.  The  request  preparat i on 
functions  are  performed  before  a  request  is  placed  on  the 
broadcast  bus.  These  functions  handle  parsing,  syntax 
checking,  and  the  transf ormati on  of  a  parsed  request  into 
the  form  required  for  processing  at  the  backends.  The 
i nser t  i nf ormati on  qenerati on  functions  are  performed  during 
the  processing  of  an  insert  request.  These  functions 
provide  additional  information  to  the  backends,  such  as  the 
identity  of  the  particular  backend  at  which  the  record  is  to 
be  inserted.  The  post  pr ocessi no  f uncti ons  are  performed 
after  replies  are  returned  from  the  backends.  For  example, 
result  data  are  collected  prior  to  forwarding  to  the  host 
computer . 

As  described  above,  the  controller  does  relatively 
little  work.  The  backends,  on  the  other  hand,  are 
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responsible  -for  all  the  major  database  management  functions. 
These  are  directory  management,  record  processing,  and 
concurrency  control .  The  directory  management  functions 
determine  the  secondary  storage  addresses  of  the  appropriate 
records  and  perform  directory  table  maintenance.  The  record 
processi nq  functions  store  records  into  secondary  storage, 
retrieve  records  from  secondary  storage,  and  select  the 
records  that  contain  the  desired  information.  The 
concurrency  control  functions  ensure  consistency  for 
concurrent  execution  of  user  requests. 

The  key  to  hi gh— perf ormance  is  in  the  parallelism  of  the 
backends.  The  database  is  distributed  across  the  disks  of 
all  of  the  backends.  Therefore,  when  a  request  is 
broadcasted  from  the  controller,  each  backend  can  execute 
the  request  on  its  portion  of  the  database.  To  yield  an 
additional  performance  advantage,  a  queue  of  requests  is 
maintained  at  each  backend.  Each  backend  schedules  requests 
for  execution  independent  of  the  activities  of  the  other 
backends. 

B.  THE  ATTRIBUTE-BASED  DATA  LANGUAGE  (ABDL) 

We  preface  our  discussion  of  the  syntax  and 
functionality  of  ABDL  with  a  brief  introduction  to  the  data 
model  supported  by  MDBS.  This  model  is  the  attribute-based 
data  model,  originally  developed  by  Hsiao  [Ref.  21.  The 
following  constructs  are  informally  defined.  A  database 
consists  of  a  collection  of  files.  Each  file  contains  a 
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unique  group  of  records.  Each  record  is  composed  of  two 
parts.  The  first  of  these  parts  is  a  collection  of 
attr ibute-val ue  pairs  or  keywords.  An  attribute-value  pair 
is  an  element  of  the  Cartesian  product  of  the  attribute  name 
and  the  domain  of  attribute  values.  As  an  example, 
<STATUS,30>  is  an  attr i bute-val ue  pair  having  30  as  the 
value  for  the  STATUS  attribute.  In  each  record,  there  is  at 
most  one  attribute-value  pair  for  each  distinct  attribute 
defined  in  the  database.  The  last  part  of  each  record 
contains  textual  information.  This  is  the  record  body.  An 
example  of  a  record  without  a  record  body  is  shown  below. 
We  note  that  all  examples  in  this  and  subsequent  sections 
are  based  on  Date's  suppl i ers-and-parts  database  as 
described  in  [Ref  91  and  in  Chapter  I. 

(  <F ILE , S>, <S# , SI > , <SNAME , Smi th > , < STATUS , 20 > , <CI TY , London >  ) 

The  first  attr i bute-val ue  pair  in  every  record  indicates  the 
file  name.  In  the  example  above,  the  file  name  is  'S'  (the 
Suppliers  file). 

The  database  can  be  accessed  through  the  use  of  keyword 
predicates .  Each  of  these  keyword  predicates  is  a  three- 
tuple  of  the  form  (attribute,  rel ati onal _operator ,  value), 
e.g.,  (STATUS  <  30).  When  keyword  predicates  are  combined 
into  a  conjunction  such  as 

((FILE  =  S)  A  (STATUS  <  30)) 
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or  into  a  disjunction  of  conjunctions  such  as 


(((FILE  =  S)  A  (SNAME  =  Smith))  V 
((FILE  =  S)  A  (SNAME  =  Jones))) 

a  query  (in  disjunctive  normal  -form)  of  the  database  is 
formed. 

In  the  following  subsections,  we  will  see  how  these 
keyword  predicates  and  queries  are  used  in  the  attribute- 
based  data  language  for  search  and  retrieval  operations.  We 
describe  the  syntax  and  f uncti onal i ty  of  the  four  types  of 
request  supported  by  ABDL:  retrieve,  insert,  delete,  and 

update.  Appendix  A  provides  a  formal  specification  of  this 
non— procedural  language. 

1 •  The  RETRIEVE  Request 

The  RETRIEVE  request  allows  the  user  to  query  the 
database  for  information.  This  operation  obtains  the 
requested  data  without  altering  the  database.  The  syntax 
is: 

RETRIEVE  (Query)  <Target— 1 i st >  EBY  attribute!  EWITH  Pointer! 

The  type  of  the  request  is  indicated  by  the  reserved  word 
RETRIEVE.  As  we  have  seen,  the  Query  part  is  composed  of 
predicates  in  the  disjunctive  normal  form.  From  our 
previous  discussion,  we  note  that  the  Query  specifies  the 
file  and  those  records  within  the  file  which  satisfy  the 


request . 


The  attributes  for  which  values  are  to  be 


extracted  -from  this  portion  of  the  database  are  contained  in 
the  Target-list.  ABDL  supports  -five  aggregate  operations: 
AVG,  COUNT,  MAX,  MIN,  and  SUM.  Therefore,  the  attribute 
value  may  be  an  aggregate  of  values  from  multiple  records, 
or  the  value  from  a  single  record. 

The  BY  and  WITH  clauses  are  optional,  as  indicated 
by  the  square  brackets  in  the  syntax.  The  BY-clause  is  used 
when  a  grouping  by  some  attribute  is  desired.  The  WITH- 
clause  specifies  whether  pointers  to  the  retrieved  records 
must  be  returned  to  the  user  for  later  use  in  an  update 
request.  As  an  example  of  a  RETRIEVE  request,  if  we  wish  to 
obtain  supplier  names  for  all  of  the  suppliers  with  STATUS 
greater  than  10,  grouped  by  location,  we  may  use  the 
following  query: 

RETRIEVE  <<FILE  =  S)  A  (STATUS  >  10))  < SN AME >  BY  CITY 

2.  The  INSERT  Request 

The  INSERT  request  alters  the  database  by  adding  a 
new  record.  The  syntax  is: 

INSERT  Record 

An  example  of  an  INSERT  request  is: 

INSERT  (  <FILE,S>,  <S#,S1>,  <SNAME,Smith>  > 

This  adds  a  record  to  the  suppliers  file  for  supplier  number 
SI  and  identifies  that  supplier  as  Smith. 
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The  DELETE  request  alters  the  database  by  removing 
an  existing  record  or  records.  The  syntax  is: 

DELETE  Query 

where  Query  specifies  which  records  are  to  be  deleted.  An 
example  of  a  DELETE  request  is: 

DELETE  ( (FILE  =  S)  A  (STATUS  =  10) ) 

This  deletes  all  records  in  the  suppliers  file  for  suppliers 
whose  status  is  equal  to  10. 

4.  Ihe  UPDATE  Request 

The  UPDATE  request  alters  the  database  by  modifying 
the  value  of  some  .attribute  in  an  existing  record.  The 
syntax  is: 

UPDATE  Query  Modifier 

where  Modifier  indicates  which  of  five  types  of  modification 
is  to  be  performed.  These  modifiers  are  defined  as  follows. 
A  type— 0  modi f i er  sets  the  new  value  of  the  attribute  being 
modified  to  a  constant.  A  type-I  modifier  sets  the  new 
value  of  the  attribute  to  be  some  function  of  its  old  value 
in  the  record  being  modified.  A  type-I I  modi f i er  sets  the 
new  value  to  be  some  function  of  another  attribute  value  in 
the  record  being  modified.  A  type-I 1 1  modi f i er  sets  the  new 
value  to  be  some  function  of  another  attribute  value  in 
another  record  identified  by  the  Query  in  the  modifier.  A 


type  IV  modi f i er  sets  the  new  value  to  be  some  -function  of 
another  attribute  value  in  another  record  identified  by  the 
pointer  in  the  modifier.  An  example  of  an  UPDATE  request 
(using  a  type— I  modifier)  is: 

UPDATE  (FILE  =  S)  < STATUS  =  STATUS  +  10 > 

which  adds  10  to  the  status  of  all  suppliers. 

C.  THE  RELATIONAL  QUERY  LANGUAGE  (SQL)  AS  THE  INTERFACE 

LANGUAGE 

AS  indicated  in  Chapter  I,  we  have  selected  the 
Structured  Query  Language  (SQL)  as  the  data  language  to  be 
supported  by  our  relational  interface  to  the  Mul ti -backend 
Database  System  (MDBS).  The  language's  commercial 

availability  coupled  with  its  simple  yet  powerful 
functionality  make  SQL  an  ideal  choice. 

In  the  preceding  section,  we  described  the  attribute- 
based  data  model  prior  to  introducing  ABDL.  However,  in 
this  section,  we  assume  a  certain  familiarity  with  the 

relational  data  model  as  we  prepare  to  describe  the  four 

basic  constructs  of  SQL:  SELECT,  INSERT,  DELETE,  and 
UPDATE.  If  the  reader  desires  a  review  of  relational 
theory,  there  are  several  very  good  texts  available.  In 
particular,  we  recommend  Date  CRef.  93  and  Ullman  [Ref.  133. 

A  discussion  of  the  mapping  between  the  relational  data 

model  and  the  attribute-based  data  model  can  be  found  in 


Banerjee  CRef.  63. 


1.  The  SELECT  Query 

Data  retrieval,  which  is  represented  syntacti cal  1 y 
as  a  SELECT— FROM-WHERE  block,  is  the  most  basic  operation  of 
SQL.  Mapping  indicates  that  a  known  quantity  (STATUS  =  30) 
is  to  be  transformed  into  a  desired  quantity  (SNAME)  by 
means  of  a  relation  <S) .  The  attributes  to  be  returned  are 
listed  in  the  SELECT  clause  (the  built-in  functions  COUNT, 
SUM,  AVG,  MAX,  and  MIN  may  be  applied  to  these  attributes). 
The  FROM  clause  indicates  which  relation  or  relations  are  to 
be  searched.  The  WHERE  clause  specifies  the  retrieval 
conditions.  As  an  example,  if  we  desire  to  obtain  the  names 
of  suppliers  whose  status  is  30,  we  may  use  the  following 
query: 

SELECT  SNAME 

FROM  S 

WHERE  STATUS  =  30 

The  SELECT  construct  allows  the  user  great 
flexibility  in  data  retrieval  operations.  The  user  can  list 
several  relations  in  the  FROM  clause  in  order  to  obtain 
values  selected  from  more  than  one  relation  (JOIN 
operations).  The  WHERE  clause  can  contain  any  number  of 
predicates  including  the  six  standard  relational  operators 
(  =  ,  A'=,  >,  >=,  <,  and  <  =  )  ,  and  the  Boolean  operators  (AND, 

OR,  and  NOT).  Parenthesis  may  be  used  to  indicate  a  desired 


order  of  evaluation 


The  set  comparison  operators  IN,  ANY 


and  ALL  may  also  be  used  in  the  WHERE  clause. 


(We 


investigate  the  use  of  these  operators  in  Chapter  IV.) 


There  are 

many  other  passible  variations 

to  the 

SELECT 

operation 

including  the 

extremel y 

useful 

nested 

SELECT. 

In  the 

nested  SELECT, 

the  result 

of  one 

SELECT 

request 

i s  used 

in  the  WHERE  clause  of 

another 

SELECT 

request . 

(The  nested  SELECT  is 

thoroughl y 

described  in 

chapter 

V.  ) 

2. 

The  INSERT 

Query 

The  INSERT  request  allows  the  user  to  insert  a  new 
tuple  (row)  or  set  of  tuples  into  an  existing  relation 
(table).  Insertion  o-f  a  single  tuple  can  be  accomplished 
through  the  use  of  a  query  such  as 

INSERT  INTO  S: 

< ' S6 ’ ,  ' Rol 1 i ns  '  ,  ' 40 ' ,  ' Newport ' > 

In  this  example,  all  of  the  attributes  are  present  and  in 
the  correct  order.  If  some  attribute  values  are  unknown, 
those  attributes  for  which  values  are  being  inserted  must  be 
listed  following  the  relation  name.  A  SQL  INSERT  statement 
may  also  evaluate  a  SELECT  request  and  insert  the  resulting 
set  of  tuples  into  an  existing  (or  temporary)  relation.  An 
example  of  such  an  INSERT  operation  is  as  follows. 


INSERT  INTO  TEMP: 


SELECT  P# 

FROM  SP 

WHERE  S#  =  ' S2 ' 

This  enters  into  TEMP  part  numbers  tor  all  parts  supplied  by 
supplier  S2. 

3.  The  DELETE  Query 

The  DELETE  specifies  tuples  to  be  removed  from  the 
database.  The  tuples  are  indicated  by  means  of  a  WHERE 
clause  that  is  syntactically  identical  to  the  WHERE  clause 
of  a  SELECT  construct.  As  an  example,  to  delete  supplier 
number  five  from  the  supplier  relation,  we  may  use  the 
following  query. 


DELETE  S 

WHERE  S#  =  ' S5 ' 

We  may  also  delete  all  shipments  with  the  query 

DELETE  SP 

The  SP  relation  is  still  known,  but  it  is  now  empty. 

4.  The  UPDATE  Query 

The  UPDATE  request  is  syntactically  similar  to  the 
DELETE  request,  except  that  a  SET  clause  is  used  to  specify 
the  updates  to  be  made  to  the  selected  tuples.  New 
attribute  values  contained  in  the  SET  clause  may  be  stated 
as  constants,  as  expressions  based  on  the  original  value  of 
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the  attribute 


or  as  nested  queries. 


An  ex amp 1 


UPDATE  request  i s 


UPDATE  S 
SET  STATUS 

WHERE  CITY  = 


=  2  *  STATUS 
' London ' 


This  doubles  the  status  of  all  suppliers  in  London 


Ill 


REVIEW  OF  BASIC  MAPPINGS 

As  we  have  described  in  Chapter  II,  the  tour  primary 
database  operations  of  the  Structured  Query  Language  (SQL) 
are  SELECT,  INSERT,  DELETE,  and  UPDATE.  Macy  [Ref.  83  has 
shown  that  for  a  subset  of  simple,  single-relation  SQL 
queries  of  all  four  types,  there  exist  direct  mappings  into 
requests  of  the  Attr i bute-based  Data  Language  (ABDL) .  These 
mappings  are  fundamental  to  all  further  SQL-to-ABDL 
translations  introduced  in  this  thesis.  Therefore,  in  the 
remainder  of  this  chapter,  we  provide  a  review  of  these 
basic  mappings  as  defined  by  Macy.  We  explain  the  mappings 
both  graphically  and  in  text.  Each  graphical  presentation 
will  display  the  general  forms  of  the  SQL  and  ABDL 
constructs,  and  the  mappings  between  them  (such  as  Figure  4, 
which  depicts  the  SELECT  to  RETRIEVE  mapping).  Sample 
translations,  utilizing  our  suppl iers-and-parts  database, 
will  be  presented  in  the  text.  The  subset  of  SQL,  for  which 
translations  are  described,  contains  those  operations  that 
Macy  has  determined  can  be  directly  supported  by  MDBS  and 
ABDL.  In  the  next  chapter,  we  will  show  that  SELECT 
requests  involving  set  comparison  operators  can  also  be 
directly  supported.  In  subsequent  chapters,  we  describe 
translations  for  SQL  constructs  such  as  the  nested  SELECT 


which  involve  multiple  ABDL  constructs. 


Prior  to  describing  the  specific  SQL  to  ABDL  mappings 


(e.g.,  SELECT  to  RETRIEVE),  we  discuss  two  general  types  of 
mapping  identified  by  Macy:  Syntactic-substitution  mapping 

and  Conversion  mapping.  Svntacti c-substi tuti on  mappi nos  are 
accomplished  by  simple  substitution  of  syntactical  terms. 
Mappings  requiring  oniy  substitution  are  denoted  by  a 
directional  arrow  labeled  with  a  square  containing  the 
letter  S  (e.g.,  the  mapping  between  the  reserved  words 
SELECT  and  RETRIEVE  in  Figure  4).  Conver si  on  mappings  are 
accomplished  by  combining  a  clause  from  an  SQL  query  with 
information  about  the  ABDL  data  structure  to  create  the 
equivalent  clause  of  the  ABDL  construct.  Mappings  requiring 
conversion  are  denoted  by  a  directional  arrow  labeled  with  a 
triangle  containing  the  letter  C  (e.g.,  the  mapping  between 
the  SQL  FROM  and  WHERE  clauses  to  the  ABDL  Query  in  Figure 
4).  We  will  describe  conversion  mappings  in  more  detail  as 
we  present  each  for  the  SQL  to  ABDL  translations.  For  an 
extensive  discussion  of  the  basic  mappings  described  in  this 
chapter ,  the  reader  is  referred  to  Macy  [Ref.  81. 

A.  MAPPING  THE  SQL  SELECT  QUERY  TO  THE 

ABDL  RETRIEVE  REQUEST 

The  mapping  from  the  SQL  SELECT  to  the  ABDL  RETRIEVE  is 
depicted  in  Figure  4.  The  mapping  proceeds  as  follows. 
The  reserved  word  SELECT  is  mapped  by  syntactic  substitution 
to  the  reserved  word  RETRIEVE.  The  sel _expr_l i st  maps 
directly  to  the  target_list.  A  conversion  mapping  is 
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required  to  translate  the  FROM  and  WHERE  clauses  to  the  ABDL 
query  clause.  This  is  accomplished  by  creating  an  equality 
keyword-predicate  for  the  relation_name,  e.g.,  FILE  = 
relation_name.  This  new  predicate  is  combined  with  the 


CBY  attribute! 


Figure  4.  Mapping  the  SQL  SELECT  to  the  ABDL  RETRIEVE 


other  predicates  listed  in  the  boolean  expression  to  form  an 
equivalent  ABDL  query  clause.  This  conversion  is  called  a 
query-conversion  mapping .  The  GROUP  BY  construct  maps 
directly  to  the  BY  construct.  As  an  example  of  a  SELECT  to 
RETRIEVE  translation,  the  following  SQL  SELECT  will,  for 
each  part  supplied,  get  the  part  number  and  the  total 


quantity  supplied  of  that  part. 


SELECT 


P# , SUM (QTY ) 


FROM  SP 

GROUP  BY  P# 

fin  equivalent  ABDL  request  is 

RETRIEVE  (FILE  =  SP)  <P# , SUM (QTY) >  BY  P# 

B.  MAPPING  THE  SQL  INSERT  QUERY  TO  THE  ABDL  INSERT  REQUEST 
The  mapping  -from  the  SQL  INSERT  to  the  ABDL  INSERT  is 
depicted  in  Figure  5.  The  mapping  proceeds  as  -follows.  The 
reserved  word  INSERT  is  the  same  -for  both  requests.  A 
conversion  mapping,  referred  to  as  a  record— conver si  on 
mapping .  in  this  case,  is  required  to  translate  "INTO 
rel ati on_name  insert_spec"  into  the  ABDL  "record" .  As  we 
have  seen  in  Chapter  II,  the  ABDL  record  is  a  series  of 
attr i bute-val ue  pairs,  the  first  pair  of  which  identifies 
the  file  name.  This  mapping,  then,  can  be  accomplished  by 


INSERT 


INSERT 


INTO  relation  name 

i nsert_spec 


Figure  5.  Mapping  the  SQL  INSERT  to  the  ABDL  INSERT 


constructing  attribute-value  pairs  for  the  rel ati on/f 1 1 e  and 
rel at i on/f i 1 e  name  and  for  the  values  of  the  attributes 


listed  in  the  insert_spec.  As  an  example  of  an  SQL  INSERT 
to  ABDL  INSERT  translation,  the  following  SQL  INSERT  query 
will  add  part  P7  (name  'Washer',  color  'Grey',  weight  '2', 
city  'Athens')  to  relation/file  P. 

INSERT  INTO  P: 

< ' P7 ' ,  ' Washer ' ,  ' Grey '  ,  '2  '  ,  ' Athens ' > 

An  equivalent  ABDL  request  is 

I NSERT  ( < F I LE , P  > , < P# , P7  > , < PNAME , Washer  > , 

<  COLOR , Grey  > , < WE I GHT , 2  > , <  C I TY , Athens  > ) 

C.  MAPPING  THE  SQL  DELETE  QUERY  TO  THE  ABDL  DELETE  REQUEST 
The  mapping  from  the  SQL  DELETE  to  the  ABDL  DELETE  is 
depicted  in  Figure  6  The  mapping  proceeds  as  follows.  The 
reserved  ward  DELETE  is  the  same  for  both  requests. 
The  query-conversion  mapping,  as  described  in  Section  A, 

DELETE 

on_name 

- - C WHERE  boolean] 


query 

Figure  6.  Mapping  the  SQL  DELETE  to  the  ABDL  DELETE 

is  used  to  translate  "relation  name"  and  "WHERE  boolean 


into  the  ABDL  query  clause. 


As  an  example  of  an  SQL  DELETE 


to  ABDL  DELETE  translation 


the  -following  SQL  DELETE  query 


will  delete  supplier  SI  -from  the  suppliers  relation. 

DELETE  S 
WHERE  S#  =  'SI  ' 

An  equivalent  ABDL  request  is 

DELETE  ((FILE  =  S)  A  (S#  =  Sl>> 

D.  MAPPING  THE  SQL  UPDATE  QUERY  TO  THE  ABDL  UPDATE  REQUEST 
The  mapping  -from  the  SQL  UPDATE  to  the  ABDL  UPDATE  is 
depicted  in  Figure  7.  The  mapping  proceeds  as  follows. 

UPDATE 


V 

UPDATE 


Figure  7.  Mapping  the  SQL  UPDATE  to  the  ABDL  UPDATE 

The  reserved  word  UPDATE  is  the  same  in  both  requests.  As 
in  Sections  A  and  C,  the  query-conver si  on  mapping  is  used  to 
translate  "relation_name"  and  "WHERE  boolean"  into  the  ABDL 
query  clause.  This  conversion  is  common  to  the 
SELECT /RETRIEVE.  DELETE.  and  UPDATE  translations.  The 


relation  name 


C WHERE  boolean! 


component  "set_clause_l ist"  directly  correlates  to  the  ABDL 
"modifier",  i.e.,  both  constructs  specify  how  the  records 
being  modified  are  to  be  updated.  To  accomplish  this 
translation,  the  modifier  conversion  mapping  is  used. 
The  conversion  required  is  a  restructuring  of  SQL 
set_clause_list  constructs  into  acceptable  ABDL  format.  The 
modif i er-conversi on  is  similar  to  the  query— conversi on.  We 
now  present  an  example  of  the  conversions  that  are  required 
in  the  translation  of  an  SQL  UPDATE  to  an  ABDL  UPDATE.  If 
we  desire  to  double  the  status  of  all  suppliers  in  london, 
we  may  use  the  following  SQL  query: 

UPDATE  S 

SET  STATUS  =  2  *  STATUS 

WHERE  CITY  =  'London' 

An  equivalent  ABDL  request  is 


UPDATE  ( (FILE 


S)  A  (CITY 


London) )  (STATUS 


2  *  STATUS) 


IV.  SELECTIONS  WITH  SET  MEMBERSHIP  OPERATIONS  ON 
SINGLE  RELATIONS 


As  we 

have  seen. 

the  condition 

foil owi ng 

the 

WHERE 

clause  in 

SQL  SELECT 

operations  may 

i nc 1 ude 

the 

normal 

comparison 

operators,  i 

.  e .  ,  =,  'v=,  etc.  Macy 

CRef. 
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shown  that  MDBS  supports  simple,  si ngl e— rel ati on  retrieval 
operations  using  these  comparison  operators.  SQL  allows  the 
use  o f  several  additional  comparison  operators.  Three  o f 
these,  IN,  ANY,  and  ALL,  deal  with  the  set  membership,  and 
are  of  particular  interest  to  us  as  we  investigate  possible 
extensions  to  the  subset  of  SQL  operations  whose  interfaces 
were  proposed  by  Macy. 

In  this  chapter  we  show  how  qualifications  using  IN, 
ANY,  and  ALL  can  be  supported  by  MDBS.  We  first  consider 
the  simple  case  where  set  members  are  enumerated  in  the 
query.  Some  of  the  examples  we  provide  herein  may  not 
appear  very  useful.  However,  they  will  serve  to  illustrate 
the  mechanics  of  SELECT  operations  using  these  comparison 
operators.  Their  usefulness  will  become  apparent  in  Chapter 
V,  when  we  use  them  in  retrievals  involving  multiple  levels 
of  nesting. 

In  sections  A,  B,  and  C,  we  formally  define  the 
comparison  operators  IN,  ANY,  and  ALL,  respect i vel y .  As 
noted  by  Chamberlin,  et.  al .  CRef.  143,  English  language 
definitions  of  these  operators  are,  at  best,  ambiguous.  We 


shall,  nevertheless,  attempt  to  explain  them  in  text  prior 
to  providing  a  clarifying  definition  in  predicate  logic.  An 
example  of  a  SELECT  query  will  then  be  given  for  each  case. 
The  result  relation  of  each  of  these  examples  will  be 
provided  in  order  to  further  clarify  the  uses  of  these 
operators.  As  in  previous  chapters,  our  examples  specify 
retrievals  of  data  contained  in  Date's  database  (defined  in 
Chapter  I).  We  will  continue  to  utilize  this  database 
throughout  this  thesis.  Again,  note  that  some  of  our 
examples  are  taken  directly  from  Date  CRef.  93.  In  Sections 
D,  E,  and  F  we  express  IN,  ANY,  and  ALL  in  the  ABDL 
requests. 

A.  IN-MEMBERSHIP  OPERATIONS 

The  comparison  operator,  IN,  can  be  thought  of  as  the 
set  membership  operator,  £  .  Correspondi ngl y ,  NOT  IN  is 
equivalent  to  $■  . 

1 .  The  Set  Membership  Operator ,  ' IN ' 

The  operator ,  IN,  is  evaluated  as  follows.  The 
condition,  A  IN  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  equal  to  at  least  one  value  in  the 
enumerated  set  B.  The  formal  definition  in  predicate  logic 
foil ows: 

Vx  (x  E  A  <==>  3y  <y  €  B  1  x  =  y)  > 
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EXAMPLE  1 : 


I f  we  wish  to  obtain  supplier  numbers  -for 


suppliers  Smith  and  Jones,  we  may  use  the 
following  query: 

SELECT  S# , SNAME 
FROM  S 

WHERE  SNAME  IN  <Smi th , Jones > 

The  result  relation  is: 

2.  The  Set  Membership  Operator ,  'NOT  IN' 

The  operator ,  NQT_IN,  is  evaluated  as  -follows.  The 
condition,  A  NOT_IN  B,  evaluates  to  be  true  i -f  and  only  if 
the  value  of  attribute  A  is  not  equal  to  any  value  in  the 
enumerated  set  B.  The  formal  definition  in  predicate  logic 
foil ows: 

Vx  <x  £  A  <==  >  \/y  (y  G  B  |  x  'v=  y) ) 

EXAMPLE  2:  If  we  wish  to  obtain  supplier  numbers  for 

suppliers  who  supply  some  parts,  but  do  not 
supply  parts  P3  or  P4 ,  we  may  use  the  following 
query: 

SELECT  S# 

FROM  SP 

WHERE  P #  NOT  IN  (P3,P4) 


The  result  relation  is: 


B.  ANY-MEMBERSHIP  OPERATIONS 

The  comparison  operator,  ANY,  is  used  in  conjunction 
with  the  six  standard  relational  operators,  =,  <=,  >=, 
<,  and  >.  It  specifies  variations  on  the  theme  of  set 
membership  as  explained  in  the  fallowing  subsections. 

1.  The  Set  Membership  Operator ,  * =ANY  * 

The  operator ,  =ANY,  is  interchangeable  with  the 
operator ,  IN.  The  condition,  A  =ANY  B,  evaluates  to  be  true 
if  and  only  if  the  value  of  attribute  A  is  equal  to  at  least 
one  value  in  the  enumerated  set  B.  Example  1  and  the 
predicate  logic  definition  given  for  the  operator  IN  apply 
equally  to  =ANY.  In  subsequent  examples  involving  set 
membership,  we  shall  use  IN  rather  than  =ANY. 

2.  The  Set  Membership  Operator  ,  ‘  'V=ANY  ' 

The  operator,  ~=ANY,  is  evaluated  as  follows.  The 
condition,  A  ~=ANY  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  not  equal  to  at  least  one  value 
in  the  enumerated  set  B.  The  formal  definition  in  predicate 
logic  follows: 


V*  <x  €  A  <==>  ^y  (y  £  B  j  x  'v=  y)  ) 


EXAMPLE  3:  If  we  wish  to  obtain  supplier  numbers  for 

suppliers  who  supply  some  parts,  but  do  not 
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we  may  use  the 


supply  both  parts  PI  and  P2, 
following  query: 


SELECT  S# 

FROM  SP 

WHERE  P#  ”'‘=ANY  (P1,P2> 


The  result  relation  is: 


S# 
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3.  The  Set  Membership  Operator .  * < =ANY ' 

The  operator,  <=ANY,  is  evaluated  as  fallows.  The 
condition,  A  <=ANY  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  less  than  or  equal  to  at  least 
one  value  in  the  enumerated  set  B.  This  implies  that  the 
value  of  attribute  A  is  less  than  or  equal  to  the  maximum 
value  in  the  set  B.  <=ANY,  then,  is  not  particularly  useful 
in  the  case  of  enumerated  sets.  The  operators  >=,  >,  and  < 
are  similarity  of  limited  value  when  sets  are  enumerated  in 
the  query.  As  previously  stated,  the  usefulness  of  these 
operators  will  become  apparent  when  we  discuss  queries  in 
which  the  results  of  one  SELECT  operation  determine  the  set 
members  in  the  WHERE  clause  of  another  SELECT  operation 
(nested  SELECT).  The  formal  predicate  logic  definition  of  A 
<=ANY  B  follows: 

Vx  (x  e  A  <==>  ^y  (ySB  j  x  <=y>)  ==> 

Vx  (x  6  A  <==>  x  <=  max  {B> ) 


As  can  be  seen  from  the  predicate  logic  definition,  when 
using  the  operator,  <=ANY,  it  is  logically  unnecessary  to 
list  more  than  one  value  (the  maximum  value)  in  the 
enumerated  set  B.  A  similar  comment  is  applicable  when 
using  >=ANY,  <ANY,  or  >ANY.  However,  in  anticipation  of  our 
nested  SELECT  discussion  in  Chapter  V,  example  queries 
utilizing  these  operators  will  each  contain  an  enumerated 
set  having  more  than  one  member.  The  additional  values 
listed  in  the  set  are  superfluous.  However,  they  will  help 
demonstrate  the  differing  results  obtained  through  the  use 
of  the  ANY  and  ALL  operators. 

EXAMPLE  4:  If  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  not  1 arger  than  30, 
we  may  use  the  fallowing  query: 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  <  = ANY  (10,20,30) 

The  result  relation  is: 


4.  The  Set  Member shi p  Operator ,  ' >=ANY ' 

The  operator  >=ANY  is  evaluated  as  follows.  The 
condition  A  >=ANY  B  evaluates  to  true  if  and  only  if  the 
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value  o-f  attribute  A  is  greater  than  or  equal  to  at  least 


one  value  in  the  enumerated  set  B.  This  implies  that  the 
value  o-f  attribute  A  is  greater  than  or  equal  to  the  minimum 
value  in  the  set  B.  The  -formal  definition  in  predicate 
logic  follows: 


V*  <x  £  A  <==>  (y  £  B  (  x  >=  y>  >  ==> 

V x  (x  £  A  <==>  x  >=  min  {B1  ) 

EXAMPLE  5:  If  we  wish  to  get  supplier  names  for  suppliers 

whose  status  is  not  less  than  10,  we  may  use 
the  following  query: 


SELECT  SNAME 
FROM  S 

WHERE  STATUS  >=ANY  (10,20,30) 


The  result  relation  is: 


SNAME 


Smi  th 
Jones 
Blake 
Clark 
Adams 


5.  The  Set  Membership  Operator .  ' < ANY ' 

The  operator,  <ANY,  is  evaluated  as  follows.  The 
condition,  A  <ANY  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  less  at  least  one  value  in  the 
enumerated  set  B.  This  implies  that  the  value  of  attribute 
A  is  less  than  the  maximum  value  in  set  B.  The  formal 
predicate  logic  definition  follows: 


Vx  < x  6  A  <==  >  x  <  max  {B>  ) 

EXAMPLE  6:  If  we  wish  to  obtain  supplier  names  -for 

suppliers  whose  status  is  less  than  30,  we  may 
use  the  -following  query: 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  < ANY  (10,20,30) 

The  result  relation  is: 


6.  The  Set  Membership  Operator .  ' >ANY ' 

The  operator ,  >ANY ,  is  evaluated  as  -follows.  The 
condition,  A  >ANY  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  greater  than  at  least  one  value  in 
the  enumerated  set  B.  The  formal  predicate  logic  definition 
f ol lows: 

Vx  <x  S  A  <==>  ^Y  (y  6  B  |  x  >  y))  ==> 

Vx  (x  e  A  <==>  x  >  min  tB> ) 

EXAMPLE  7:  If  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  greater  than  10,  we 
may  use  the  following  query: 


SELECT 


SNAME 


FROM  S 

WHERE  STATUS  >ANY  (10,20,30) 


The  result  relation  is: 


BNAME 


Smith 
B1  ake 
Cl  ark 
Adams 


C.  ALL-MEMBERSHIP  OPERATIONS 

Like  the  comparison  operator,  ANY,  the  operator,  ALL,  is 
used  in  conjunction  with  the  six  standard  relational 
operators.  It  also  specifies  variations  on  the  set 
membership  theme. 

1 .  The  Set  Membership  operator .  ' =ALL  * 

The  operator,  =ALL,  is  evaluated  as  -follows.  The 
condition,  A  =ALL  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  equal  to  every  (each)  value  in  the 
enumerated  set  B.  The  formal  predicate  logic  definition 
f ol lows: 


Vx  (x  6!  A  <  == 

Vy  <Y  €  B 


3  Y  (y  £  B  |  x  =  y))  A 
==>  3*  (x  E  A  |  x  =  y)  ) 


From  this  definition,  it  is  apparent  that  the  set  B,  whether 
manually  enumerated  or  determined  by  the  results  of  an  inner 
SELECT,  would  contain  only  one  value  (or  duplicates  of  that 


val ue) . 


Ther ef ore 


since  we  can  always  use  a  condition  of 


the  -form  WHERE  STATUS  =  30,  we  shall  not  use  the  operator 
=ALL  in  -further  discussion  or  examples. 

2.  The  Set  Membershi  p  Operator  .  '  "J=ALL  ' 

The  operator,  'V=ALL,  is  i  nterchangeab  1  e  with  the 
operator,  N0T_IN.  The  condition,  A  ~=ALL  B,  evaluates  to  be 
true  if  and  only  if  the  value  of  attribute  A  is  not  equal  to 
every  value  in  the  enumerated  set  B.  In  other  words,  there 
is  no  value  in  the  set  B  to  which  the  value  of  attribute  A 
is  equal.  The  predicate  logic  definition  of  N0T_IN  is 
repeated  for  clarity: 


V*  <*  6  a  <==>V y  <y  €  b  |  *  ~=  y>  > 


The  query  given  in  example  2  (with  'V=ALL  substituted  for  NOT 
IN)  is  applicable.  In  subsequent  examples  involving  set 
membership,  we  shall  use  NOT  IN  rather  than  'V=ALL. 

3.  The  Set  Membership  operator  .  '  =ALL  ' 

The  operator ,  <=ALL,  is  evaluated  as  follows.  The 
condition,  A  <=ALL  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  less  than  or  equal  to  every 
value  in  the  enumerated  set  B.  This  implies  that  the  value 
of  attribute  A  is  <=  the  minimum  value  in  set  B.  The 
predicate  logic  definition  follows: 

Vx  (x  €.  A  <==>  \/y  (y  E  B  |  x  <=  y>)  ==> 

Vx  (x  £  A  <==>  x  <—  min  (B> ) 


Again,  as  in  the  case  of  the  operator  ANY,  our  degenerate 


•  •  .  •  ,‘vt  •  •  -  *  ■  .*•  «*'  •"*  .  •  .*•  %'•  .*•  •'*  «*»  ,vV 
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examples  utilising  the  operators  <=ALL,  >=ALL ,  <ALL,  and 
>ALL  will  be  presented  with  enumerated  sets  containing  more 
than  one  member  (even  though,  logically,  only  one  member  is 
necessary) . 


EXAMPLE  8:  If  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  not  greater  than  10, 
we  may  use  the  following  query: 


SELECT  SNAME 
FROM  S 

WHERE  STATUS  <  = ALL  (10,20,30) 


The  result  relation  is: 


SNAME 


Jones 


Note  that  the  difference  between  the  comparison  operators 
ANY  and  ALL  is  readily  apparent  when  we  compare  this  example 
with  example  4.  In  example  4,  the  operator,  <=ANY,  allows  u 
to  obtain  supplier  names  for  suppliers  whose  status  is  not 
larger  than  30.  The  result  relation  in  that  example 
includes  the  names  of  all  five  suppliers. 

4.  The  Set  Membershi p  Operator ,  ' >=ALL ’ 

The  operator,  >=ALL ,  is  evaluated  as  fallows.  The 
condition,  A  >=ALL  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  greater  than  or  equal  to  every 
value  in  the  enumerated  set  B.  This  implies  that  the  value 


of  attribute  A  is  greater  than  or  equal  to  the  maximum  value 


in  set  B.  The  predicate  logic  definition  follows: 

V>:  <x  €  A  C  ==  >  V V  <y  6  B  |  >:  >=  y  >  >  ==> 

V::  £  A  <==>  >;  >=  max  CB1  ) 

EXAMPLE  9:  If  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  at  least  30,  we  may 
use  the  following  query: 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  >=ALL  (10,20,30) 

The  result  relation  is:  SNAME 

B1  ake 


5.  The  Set  Membership  operator ,  ' < ALL ' 

The  operator,  CALL,  is  evaluated  as  follows.  The 
condition,  A  CALL  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  less  than  every  value  in  the 
enumerated  set  B.  The  predicate  logic  definition  follows: 

V x  (>:  €  A  <==>Yv  <y  6  B  |  x  <  y))  ==> 

Vx  <X  €  A  <==>  >;  <  min  CB}  > 


EXAMPLE  10:  if  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  less  than  10,  we 
may  use  the  following  query: 


•  -*1 


*.  *.  *.  A  *. 
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SELECT 


SNAME 


FROM  S 

WHERE  STATUS  CALL  (10,20,30) 


The  result  relation  is: 


SNAME 


Note  that  this  is  the  empty  relation.  There  are  no 

suppliers  whose  status  is  less  than  10. 

6.  The  Set  Member shi p  Operator ,  ' >ALL  ' 

The  operator ,  >ALL ,  is  evaluated  as  follows.  The 
condition,  A  >ALL  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  greater  than  every  value  in  the 
enumerated  set  B.  The  predicate  logic  definition  follows: 


V x  <>:  €  a  <==> Vy  <Y  €  B  | 
Vx  £  a  <==>  >:  >  max 


x  >  y ) >  ==> 

CB7  ) 


EXAMPLE  11:  If  we  wish  to  obtain  supplier  names  for 

suppliers  whose  status  is  greater  than  30,  we 
may  use  the  following  query: 


SELECT  SNAME 
FROM  S 

WHERE  STATUS  : ALL  (10,20,30) 


The  result  relation  is: 


SNAME 


As  in  example  10,  this  is  the  empty  relation.  There  are  no 
suppliers  whose  status  is  greater  than  30. 


D.  EXPRESSING  IN-MEMBERSHIP  OPERATIONS  IN  ABDL 

In  this  and  the  -following  two  sections,  we  present  ABDL 
translations  for  the  examples  given  in  sections  A,  B,  and  C. 
Each  SQL  example  will  be  repeated,  followed  by  the  ABDL 
transl ati on. 

1 .  The  Set  Member shi p  Operator ,  ' IN ' 

The  SQL  query  presented  as  example  1  is 

SELECT  S# , SNAME 
FROM  S 

WHERE  SNAME  IN  (Smith , Jones) 

Our  proposed  SQL  interface  would  provide  the  following  ABDL 
translation: 

RETRIEVE  (((FILE  =  S)  /\  (SNAME  =  Smith))  V 

((FILE  =  S)  A  (SNAME  =  Jones)))  <S# , SNAME  > 

One  conjunction  is  created  for  each  value  in  the  enumerated 
set,  containing  an  equality  predicate.  The  ABDL  request 
will  have  as  many  conjunctions  as  there  are  values  in  the 
set . 

2.  The  Set  Member shi p  operator .  'NOT  IN' 

The  SQL  query  presented  as  example  2  is 

SELECT  S# 

FROM  SP 


WHERE 


P#  NOT  IN  (P3,P4) 


The  ABDL  translation  is 


RETRIEVE  ((FILE  =  SP)  A  (P#  ''*=  P3)  A  (P#  P4>  <S#> 

One  predicate  of  the  form  (attribute  ''*=  value)  is  created 
•for  each  value  in  the  enumerated  set.  The  ABDL  request  will 
contain  a  single  conjunction,  which  is  the  logical  AND  o-f 
these  predicates. 

E.  EXPRESSING  ANY-MEMBERSH I P  OPERATIONS  IN  ABDL 

1 .  The  Set  Member sh i p  Oper ator ,  * =ANY 1 

As  previously  de-fined,  =ANY  is  equivalent  to  IN  and 
will  not  be  included  in  our  set  o-f  allowable  SQL  constructs. 

2.  The  Set  Membership  Operator ,  *  **'=ANV  ' 

The  SQL  query  presented  as  example  3  is 

SELECT  S# 

FROM  SP 

WHERE  P#  'V=ANY  (P1,P2> 

The  ABDL  translation  is 


RETRIEVE  (((FILE  = 

SP) 

A 

(P# 

PI ) ) 

( (FILE  = 

SP) 

A 

(P3 

■v=  P2)  )  ) 

One  conjunction  is  created  for  each  value  in  the  enumerated 
set,  containing  a  predicate  of  the  form  (attribute  "“= 
val ue> . 

3.  The  Set  Membership  Oper ator .  ' <=ANY ' 

The  SQL  query  presented  as  example  4  is 


SELECT 


SNAME 


FROM  S 

WHERE  STATUS  OANY  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =S)  A  (STATUS  <=  30))  < SNAME > 

One  predicate  of  the  -form  (attribute  <=  max_value)  is 

created.  The  ABDL  request  will  contain  a  single 

conjunction.  Note  that  the  SQL  interface  recognises  that 
the  condition  in  the  WHERE  clause  evaluates  to  true  if  and 
only  if  a  supplier's  status  is  less  than  or  equal  to  at 
least  one  of  the  status  values  in  the  enumerated  set 
(implying  that  that  supplier's  status  is  less  than  or  equal 
to  the  maximum  value  in  the  set).  Therefore,  only  the 
maximum  value,  30,  is  utilised  in  the  ABDL  translation. 

4.  The  Set  Membership  Operator .  ' >=ANY ' 

The  SQL  query  presented  as  example  5  is 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  >=ANY  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A  (STATUS  >=  10) >  < SNAME  > 

One  predicate  of  the  form  (attribute  >=  min_value)  is 
created.  The  ABDL  request  will  contain  a  single 
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conjunction.  As  in  the  '<=ANY'  case,  only  one  value  o-f  the 
enumerated  set  in  the  WHERE  clause  is  utilised  in  the  ABDL 
translation.  In  this  case,  the  minimum  value,  10,  is 
utilized. 

5.  The  Set  Membership  Operator ,  ' < ANY ' 

The  SDL  query  presented  as  example  6  is 


SELECT  SNAME 
FROM  S 

WHERE  STATUS  CANY  (10,20,30) 


The  ABDL  translation  is 


RETRIEVE  ((FILE  =  S)  A  (STATUS  <  30))  < SNAME > 


One  predicate  af  the  form  (attribute  <  max_value)  is 
created.  The  ABDL  request  will  contain  a  single 
con  junction . 

6.  The  Set  Membership  Operator .  ' >ANY ' 

The  SQL  query  presented  as  example  7  is 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  >ANY  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =S>  A  (STATUS  >  10))  < SNAME > 


One  predicate  of  the  -form  (attribute 


min  value)  is 


created.  The  ABDL  request  will  contain  a  single 

conjunction. 

F.  EXPRESSING  ALL-MEMBERSHIP  OPERATIONS  IN  ABDL 

1.  The  Set  Membership  Operator ,  '  =ALL  ' 

As  previously  defined,  use  of  the  operator,  =ALL ,  is 
equivalent  to  using  the  standard  equality  operator,  =.  We 
will,  therefore,  not  include  it  in  our  set  of  allowable  SQL 
constructs. 

2.  The  Set  Membershi  p  Operator  .  '  "“=ALL  ‘ 

As  previously  defined,  "'=ALL  is  equivalent  to 
NOT  IN  and  will  not  be  included  in  our  set  of  allowable  SQL 
constructs. 

3.  The  Set  Membership  Operator .  ' <  =ALL ' 

The  SQL  query  presented  as  example  B  is 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  <=ALL  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S>  A  (STATUS  <=  10) >  <  SNAME  > 


One  predicate  of  the  f 
created.  The  ABDL 
conjunction.  As  in  the 
SQL  interface  utilizes 


orm  (attribute  <=  min_value)  is 
request  will  contain  a  single 
'<=ANY'  case,  the  translator  in  our 
only  one  value  from  the  enumerated 
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set.  Note  that  in  this  case,  the  minimum  value,  10,  is 
chosen,  whereas,  in  the  '<=ANY'  case  the  maximum  value,  30, 
is  chosen. 

4.  The  Set  Membership  Operator ,  ' >=ALL ' 

The  SQL  query  presented  as  example  9  is 
SELECT  SNAME 

FROM  S 

WHERE  STATUS  >=ALL  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ( (FILE  =  S)  A  (STATUS  >=  30) )  < SNAME > 

One  predicate  o-f  the  -form  (attribute  >=  max_value)  is 
created.  The  ABDL  request  will  contain  a  single 

conjunction.  As  in  the  ' >=ANY '  case,  only  one  value  of  the 
enumerated  set  is  utilized.  In  this  case,  the  maximum 
value,  30,  is  utilized  in  the  equivalent  RETRIEVE  construct. 
We  recall  that  the  minimum  value,  10,  was  utilized  in  the 
' >=ANY '  case. 

5.  The  Set  Member shi p  Operator ,  ' < ALL ' 

The  SQL  query  presented  as  example  10  is 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  <ALL  (10,20,30) 


The  ABDL  translation  is 


RETRIEVE  ((FILE 


S)  /  (STATUS  <  10))  < SNAME 


One  predicate  of  the  form  (attribute  <  min_value)  is 

created.  The  ABDL  request  will  contain  a  single 

conjunction. 

6.  The  Set  Membershi p  Operator ,  ' >ALL  ' 

The  SQL  query  presented  as  example  11  is 

SELECT  SNAME 
FROM  S 

WHERE  STATUS  >ALL  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A  (STATUS  >  30))  < SNAME > 

One  predicate  of  the  form  (attribute  max_value)  is 

created.  The  ABDL  request  will  contain  a  single 


V.  SELECTIONS  WITH  SET  MEMBERSHIP  OPERATIONS  ON 
MULTIPLE  RELATIONS 

In  the  preceding  chapter,  we  have  described  SDL  SELECT 
queries  which  utilize  the  comparison  operators,  IN,  ANY,  and 
ALL  in  the  WHERE  clause.  These  are  simple,  si ngl e-rei at i on 
queries  in  which  the  associated  sets  are  enumerated.  We  now 
discuss  the  nested  SQL  SELECT  queries  (or  nested  mapping)  in 
which  the  result  of  one  mapping  is  used  in  the  WHERE  clause 
of  another  mapping.  In  other  words,  the  membership  of  the 
set  following  IN,  ANY,  or  ALL  in  one  SELECT  operation  is 
determined  by  the  result  set  of  another  SELECT.  We  will 
describe  the  operation  of  two— level,  three— level  and  n— level 
nested  SELECTS  in  Sections  A,  B,  and  C,  respecti vel v .  In 
Section  D,  we  show  how  the  nested  SDL  SELECT  is  translated 
into  a  series  of  ABDL  RETRIEVES. 

A.  NESTED  SELECTIONS  WITH  TWO  RELATIONS 

As  previously  stated,  in  a  nested  SDL  SELECT,  the 
results  of  one  SELECT  operation  are  used  in  the  WHERE  clause 
of  another  SELECT  operation.  We  view  the  former  SELECT  as 
the  inner  (level  of)  SELECT,  and  the  latter  as  the  outer 
(level  of)  SELECT.  Figure  S  depicts  an  example  of  a  two- 
level  nested  SELECT  operation.  This  particular  example  is 
chosen  for  its  similarity  to  one  of  our  examples  in  Chapter 

,  < ANY ,  i n 


IV  ( i  .  e. 


Example  6)  which  utilizes  the  operator 


conjunction  with  a 


manually  enumerated  set. 


In  the 


degenerate  case  presented  in  that  example,  the  operator, 
<ANY,  appeared  to  be  of  marginal  usefulness.  The  usefulness 
of  this  and  similar  operators  (e.g.,  <=ANY,  >=ALL)  in  the 
nested  SELECT,  will  now  become  apparent. 

Both  our  current  example  in  Figure  S,  and  Example  6  of 
Chapter  IV  result  in  a  set  of  supplier  numbers  for  suppliers 
with  status  value  less  than  the  current  maximum  status  value 
in  the  S  table.  In  our  degenerate  example,  we  must  know 
(i.e.,  enumerate)  that  that  value  is  30.  In  our  present 
example,  we  allow  an  inner  SELECT  to  obtain  the  status  value 
for  each  supplier  number  in  the  S  table.  By  employing  an 
inner  level  of  SELECT,  we  are  free  from  enumerating  the 
val ues. 


Outer  | 

select! 

Inner  j 
SELECT 
Figure  8. 


SELECT  S# 

FROM  S 

WHERE  STATUS  CANY 

(SELECT  STATUS 
FROM  S) 

A  Two-Level  Nested  SELECT 


Processing  of  the  two-level  nested  SELECT  in  Figure  8 
proceeds  as  follows.  First,  the  inner  SELECT  retrieves  all 
status  values  in  the  S  table.  The  result  of  this  SELECT  is 
the  set  (with  dciplicates)  of  status  values  {20,10,30,20,301. 


The  outer  SELECT  then  selects  supplier  numbers  FROM  table  S 
WHERE  the  status  value  is  less  than  at  least  one  of  the 
values  in  the  above  result  set.  The  result  relation  is 

S# 

51 

52 

S4 

B.  NESTED  SELECTIONS  WITH  THREE  RELATIONS 

We  now  describe  a  three-level  nested  SELECT.  We  present 
an  example  which  demonstrates  the  use-fulness  of  the 
set/comparison  operator  IN,  and  of  multi-level  SELECTS  in 
general.  In  the  course  of  providing  the  requested  data, 
this  three— level  SELECT  chooses  data  from  each  of  the  three 
tables  which  comprise  our  sample  database.  The  request  is 
to  get  supplier  names  far  suppliers  who  supply  at  least  one 
red  part.  The  query  is  presented  in  Figure  9. 


Outermost 

SELECT 


SELECT 

FROM 

WHERE 


Inner 
SELECT I 


SNAME 

S 

S#  IN 
(SELECT 
FROM 
WHERE 


Innermost 

SELECT 


S# 

SP 

P#  IN 
(SELECT 
FROM 
WHERE 


P# 

P 

COLOR  = 


RED  '  )  ) 


Figure  9.  A  Three-Level  Nested  SELECT 


Processing  o-f  the  query  in  Figure  9  proceeds  as 
toll ows. 

Step  1:  The  innermost  SELECT  retrieves  part  numbers 
(F'#>  from  the  parts  relation  (P)  where  the  color 
of  the  parts  is  red.  The  result  of  this  SELECT 
is  the  set  of  part  numbers  IP1,P4,P61. 

Step  2:  The  next  SELECT  retrieves  supplier  numbers  (S#> 
from  the  shipments  relation  (SP)  where  P#s  are 
in  the  result  set  of  step  1.  The  result  of  this 
SELECT  is  the  set  of  supplier  numbers  CS1,S2,S4>. 

Step  3:  The  outermost  SELECT  retrieves  supplier  names 

(SNAME)  from  the  suppliers  relation  (S)  where 
S#s  are  in  the  result  set  of  step  2.  The  result 
relation  passed  to  the  user  is 


C.  NESTED  SELECTIONS  WITH  N  RELATIONS 

Although  it  seems  unlikely  that  many  users  would  utilise 
a  nested  SELECT  of  more  than  2  or  3  levels,  the  subqueries 
can  be  nested  to  any  depth.  The  form  of  an  n— level  nested 
SELECT  is  shown  in  Figure  10. 

The  SET_0PR  in  Figure  10  refers  to  the  various  forms  of 
our  comparison  operators  IN,  ANY,  and  ALL.  In  the  next 
section,  we  describe  the  translation  of  nested  SELECTS  to  a 
series  of  ABDL  RETRIEVES.  Therefore,  it  is  important  that 


SELECT  sel _expr_l i st 
FROM  rel  ation_name_l 

WHERE  attri bute_namel  SET_QPR 
<SELECT  attri bute_namel 
FROM  rel at i on_name_2 
WHERE  attri bute_name2  SET_OF'R 

(SELECT  attr ibute_name (n-1 ) 

FROM  r el  ati  on__name_n 

WHERE  condition)...) 

Figure  10.  An  N-Level  Nested  SELECT 

we  note  the  Fallowing  information  as  succinctly  stated  in 
CReF.  ID. 

"The  nth  level  is  the  i nnermost  SELECT.  The  1st 
level  is  the  outermost  SELECT.  The  sel  _expr  __1  i  st  oF  each 
i nner  SELECT,  i.e. ,  a  SELECT  lower  than  level  1,  contains 
a  single  attribute  name,  which  is  the  same  as  the 
attribute  name  used  in  the  qual i F i cat i on  oF  the  next- 
higher  level  SELECT.  The  relation  names  at  any  two  levels 
may  be  the  same. " 

D.  TRANSLATIN6  NESTED  SELECTIONS  TO  A  SERIES  OF  ABDL 
RETRIEVALS 

As  shown  by  Macy  EReF.  83,  there  exists  a 
straightForward  mapping  between  the  SOL  SELECT  operation  and 
the  ABDL  RETRIEVE  operation.  We  can,  therefore,  simulate 
the  nested  SELECT  with  a  series  oF  RETRIEVES,  each 
succeeding  operation  using  the  results  oF  the  previous  one. 
Thus,  reFerring  to  our  three-level  example  oF  Section  B,  the 


ABDL  equivalent  of  the  innermost  SELECT  is 

RETRIEVE  ((FILE  =  P)  A  (COLOR  =  'RED'))  vP#/ 


The  resulting  set  of  part  numbers  £P1,P4,P6>  is  then  used  in 


next  ABDL 

operation 

as 

foil ows: 

RETRIEVE 

(  ( (FILE  = 

SP) 

A 

(P#  =  PI ) ) 

V 

( (FILE  = 

SF’) 

A 

(P#  =  F‘4)  ) 

V 

( (FILE  = 

SP) 

A 

(P#  =  P6) ) ) 

<S# 

The  last  retrieve  (corresponding  to  the  outermost  SELECT  in 
our  example)  then  uses  the  resulting  set  of  supplier  numbers 
151,52,543  as  follows: 

RETRIEVE  (((FILE  =  S)  A  (S#  =  Sl>)  V 

((FILE  =  S)  A  (S#  =  S2> )  V 

((FILE  =  S)  A  (S#  =  S4))>  <  SNAME  > 

It  is  intended  that  the  operation  of  our  SQL  interface  be 
transparent  to  the  SQL  user.  Therefore,  the  resulting 
values  of  the  attribute  SNAME  ( Smi th , Jones , Cl ar k )  are 

returned  to  the  user  in  the  form  of  the  result  relation 
previously  described  for  our  three-level  nested  SELECT 
example  of  section  B. 

We  have  now  demonstrated  the  operation  of  data 
retrievals  involving  the  nested  SELECT  construct.  These 
nested  operations  may  include  use  of  the  various  forms  of 
IN,  ANY,  and  ALL.  The  sequence  of  actions  necessary  to 


translate  the  nested  SQL  SELECT  to  a  series  of  ABDL 
RETRIEVES  has  been  described.  In  the  next  chapter,  we 
present  our  proposals  for  the  implementation  of  these 
transl at i ons. 


VI.  IMPLEMENTING  NESTED  SELECTIONS 

The  logical  process  by  which  a  nested  SQL  SELECT  is 
translated  to  a  series  of  ABDL  RETRIEVES  has  been  described. 
It  is  clear  that  each  SELECT  level,  -from  the  innermost  to 
the  outermost,  must  be  translated  to  an  ABDL  RETRIEVE. 
Then,  each  RETRIEVE  is  processed  in  turn,  with  each 
succeeding  operation  utilizing  the  results  o-f  the  previous 
RETRIEVE  in  the  QUERY  part.  In  Section  A  o-f  this  chapter,  we 
present  the  algorithms  -for  building  the  ABDL  QUERY.  In 
Section  B,  a  simple  iterative  structure  for  controlling  the 
execution  of  n— level  nested  SELECTS  is  provided.  Final lv, 
in  Section  C,  the  overal  1  software  structure  o-f  our  SQL 
interface  will  be  proposed.  Note  that,  as  we  continue  our 
bottom-up  investigation  and  include  additional  SQL 
operations  in  our  set  of  allowable  constructs,  the 
functionality  of  this  structure  may  be  augmented.  However, 
it  is  expected  that  the  software  structure  will  remain 
i ntact . 

A.  ALGORITHMS  FOR  BUILDING  THE  ABDL  QUERY 

We  recall  that  the  Query  part  of  ABDL  RETRIEVES  (DELETE 
and  UPDATE,  as  well)  is  written  in  a  disjunctive  normal 
form.  A  QUERY  may  be  a  single  conjunction  or  it  mav  be  a 
disjunction  of  conjunctions.  The  number  of  conjunctions 
generated  in  the  translation  of  nested  SELECTS  utilizing  the 


various  forms  of  IN,  ANY,  and  hLL  has  been  noted  in  Sections 
D,  E,  and  F  of  Chapter  IV.  Figure  11  summarizes  this 
information.  The  figure  also  specifies  the  relational 
operators  involved,  as  well  as  the  source  of  the  values  to 
be  used  in  each  conjunction. 

Set  0 Dr  #  Conjunctions  Rel  Odt  Value  Source 


IN 

n 

— 

result  set 

NOT  IN 

1 

'Vi _ 

result  set 

'V=ANY 

n 

result  set 

<=ANY 

1 

<  = 

max (resul t 

set ) 

>=ANY 

1 

min (resul t 

set ) 

CANY 

1 

c 

max (resul t 

set  > 

;  ANY 

1 

’> 

mi  n (resul t 

set ) 

<=ALL 

1 

<  at 

mi n (resul t 

set ) 

>=ALL 

1 

>= 

max (resul t 

set ) 

CALL 

1 

< 

mi n (result 

set  > 

■  ALL 

1 

> 

max (resul t 

set ) 

Figure 

11. 

Summary  of  Nested  SELECT 

Set  Comparison  Operators 

From 

Figure 

11, 

it 

is  clear 

that  our  translator 

must 

perform 

a  multiway 

sel ecti on 

depending  upon  which  set 

comparison  operator 

is  utilized 

at 

each  SELECT  level 

.  We 

describe 

an  appropriate 

algorithm  in  Subsection  1. 

It  can 

also  be 

seen  that. 

i  n 

the  case 

o-f 

the  operators  IN  and 

"'=ANY ,  a  number  of  conjunctions  are  generated,  one  for  each 
value  in  the  result  set  of  the  previous  operation.  In 
Subsection  2,  we  present  an  n-con junct i on  algorithm  to 
handle  these  two  cases.  Note  that  in  all  remaining  cases,  a 
single  conjunction  is  generated.  The  1 -con junct 1  on 
algorithm  is  presented  in  Subsection  3. 

1 .  The  Query -Con struct or  Subr out i ne 

As  noted  above,  the  top-level  translator  portion  of 
our  SQL  interface  must  determine  from  the  set  comparison 
operator  the  proper  algorithm  for  constructing  the  QUERY 
part  of  the  resultant  ABDL  request.  This  can  be  handled  bv 
a  multi-way  selection  or  CASE  construct,  as  shown  in  the 
Query-Constructor  Algorithm  in  Figure  12.  The  parameters 
passed  to  Quer yConstructor  are  Query  Template  (a 
conjunction,  described  in  Subsection  2,  constructed  to 
facilitate  the  incorporation  of  succeeding  result  sets),  the 
Result_Set  of  the  previous  request,  and  the  appropriate 
Set_Dpr  from  Figure  11. 

In  each  alternative  of  the  CASE  statement  of  Figure 
12,  the  correct  relational  operator  is  chosen,  and  either 
the  n-con junct i on  or  the  1 -can junction  subroutine  is  called. 
The  parameters  provided  for  each  subroutine  call  are  the 
relational  operator  and  the  resul t  set  of  the  previous 
operation,  or  the  maximum/minimum  value  of  the  result  set. 
As  previously  discussed,  when  ANY  and  ALL  are  used  with 
these  relational  operators,  only  one  value  of  the  result  set 
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Subroutine  Query_Constructor (Query_Templ ate , Resul t_Set , 

Set  _Qpr ) 

CASE  Set  _Opr  OF 

IN:  Rel_Opr  < —  '=' 

call  N_con juncti on ( Quer y_Templ ate , Resul t_Set , 

Rel _Opr ) ; 

NOT  IN:  Rel  _Opr  < —  ' 'v= ' 

call  One  _cori  juncti  on  (Quer  y_Templ  ate ,  Resul  t  _Set  , 

Rel _Opr ) ; 

~=ANY:  Rel _Opr  < — 

cal  1  N_con  junction (Query_T empl ate , Resul  t_Set , 

Rel _Qpr  > ; 

<  =ANY :  Rel _Opr  < —  '<=' 

cal  1  One_con  juncti  on ( Quer y_T empl ate , 

max (Resul t_Set) , Rel_Opr> ; 

>=ANY :  Rel _Opr  < —  ' >= ' 

call  One_con  junction ( Quer y_Templ ate , 

min (Result_Set) ,Rel_Qpr) ; 

<  AN Y :  Rel  _Qp r  <  —  '  <  ' 

cal  1  One__con  junction  (Query_Templ  ate , 

max (Resul t_Set) , Rel  Opr) ; 

>ANY :  Rel_Opr  < —  ’>' 

cal 1  One_conjunction (QueryTempl ate, 

mi n (Resul t_Set ) , Rel _Opr ) ; 

< = ALL :  Rel _Opr  < —  '<=' 

cal 1  One_con juncti on (Query_Templ ate , 

mi n (Resul t_Set ) , Rel _Opr )  ; 

>=ALL:  Rel _Opr  < —  ' >= ' 

cal  1  One_con junction (Query_Tempi ate, 

max (Resul t_Set) ,Rel_Opr> ; 

<ALL:  Rel_Opr  < —  '<* 

cal  1  One_con junct i on (Ouery_Template, 

mi n ( Resul t_Set ) , Rel _Opr ) ; 


>ALL:  Rel _Opr  < —  *>' 

cal  1  One_con  juncti on (Query_Templ ate , 

max (Resul t_Set) ,Rel _Opr ) ; 

END  CASE 

END  Quer y__Constr uctor 


Figure  12 


The  Query__Constructor  Subroutine 


is  utilised  in  the  translation.  Depending  upon  which  -form 
o-f  the  set  comparison  operator  is  used.  the  selected  value 
will  be  either  the  maximum  or  the  minimum  value  in  the 
result  set.  Therefore,  a  call  to  a  standard  Max  or  Min 
function,  as  appropriate,  must  be  made  prior  to  sending  the 
resultant  single  value  to  the  1-conjunction  subroutine.  It 
should  be  noted  that  the  1-con junction  subroutine  is  called 
in  the  case  of  the  operator  NOT  IN.  However,  there  is  no 
need  to  utilize  a  Max /Min  -function.  We  also  note  that  a 
call  to  Max/Min  is  never  needed  prior  to  a  call  to  the  n  — 
conjunction  subroutine. 

2.  The  N— Con junct i on  Subrout i ne 

In  the  case  o-f  the  set  operators  IN  and  ~=ANY .  the 
above  Query-Constructor  subroutine  will  call  the  n- 
con junction  subroutine.  In  the  process  of  translating 
nested  SELECTS  which  utilize  these  operators,  one 
conjunction  of  the  form 

((FILE  =  Relname)  /A  (Attrname  Rel _opr  Value)) 

will  be  generated  for  each  value  in  the  result  set.  These 
conjunctions  are  ORed  to  form  a  disjunction  of  conjunctions, 
as  explained  in  Chapter  IV,  Sections  D  and  E.  An 
algorithmic  repr esentati on  of  the  n-con juncti on  generation 
subroutine  is  provided  in  Figure  13. 

The  template,  defined  in  Figure  13,  is  provided  by 


the  top-level  translator  as  it  translates  each  SELECT  level 


to  an  ABDL  RETRIEVE.  Val ue_of _Templ ate  is  the  only  variable 
which  requires  substitution.  For  the  innermost  (nth  level) 
SELECT  of  a  nested  SELECT  request,  the  equivalent  RETRIEVE 
can  be  constructed  completely.  However,  at  translation 
time,  the  values  to  be  used  in  the  query  portion  o-f  the 


Subroutine  N_con juncti on <Query_Templ  ate , Rel  _opr ) 


/'*  Ouery_Templ ate:  * / 
/*  is  ((FILE  =  Relname)  A  (Attrname  Rel_opr  Value))  */ 
/*  Query:  #/ 
/*  is  Quer y_Temp  1  ate  V  Query_Templ  ate  V  .  .  .  #/ 
/*  V  Query_Templ ate  ♦  / 
/*  */ 
/*  For  every  value  in  the  Result_set  ♦  / 
/*  generate  one  conjunction  using  Template  ♦  / 
/*  then  OR— concatenate  into  Query.  ♦  / 


Rel  _opr  _of  _Templ  ate  < —  Rel_opr 

if.  Result _set  is  NOT  EMPTY 
then 

Val ue_of _Templ ate  < —  1st  value  from  Result _set 
Query  < —  Query_Template  /*  Relname  ?c  Attrname  */ 

/♦filled  in  ♦  / 

while  more  values  in  Result_set  do 

Val ueof _Templ ate  < —  next  value  from  Resultset 
Query  < —  Query  ! !  '  V'  ! !  Template 

end  whi 1 e 
el  se 

Query  < —  '  '  /♦  Query  is  nil  ♦/ 

END  N_con junction 

Figure  13.  The  N-con junct i on  Subroutine 


remaining  n-1  SELECTS  are  unknown.  Therefore,  the  template 
is  provided  to  the  N-con junction  generator  which  fills  in 
the  missing  values  and  constructs  the  QUERY  part  of  each 


RETRIEVE. 


In  the  case  of  the  operator  NOT  IN  and  all  of  the 


ANY/ALL  operators  containing  <=,  >=,  <,  or  > ,  the  CASE 
statement  causes  a  call  to  the  1— con junction  subroutine.  As 
described  in  Chapter  IV,  one  predicate  o-f  the  form 
(Attribute  Rel_opr  Value)  is  generated  for  each  value  in  the 
result  set.  These  predicates  are  then  ANDed  to  form  a 
single  conjunction.  An  algorithmic  representation  of  the  1- 
con junction  subroutine  is  provided  in  Figure  14. 


Subroutine  Onecon junction (Query_Templ ate,Resul t_set , 

Rel _opr ) 


/*  Query_Templ ate:  *-/ 
/*  is  ((FILE  =  Relname)  A  (Attrname  Rel _opr  Value))  *■/ 
/*  Predicate:  */ 
/*  is  (Attrname  Rel_opr  Value)  */ 
/*  Query:  */ 
/*  is  Query_Template  A  Predicate  A  .  .  .  */ 
/*  A  Predicate  */ 


Strip  right  paren  from  Query_Templ ate 
Rel _opr_of _Templ ate  < —  Rel_opr 

i±  Result _set  is  NOT  EMPTY 
then 

Val ue_of _Templ ate  < —  1st  value  from  Result_set 
Query  < —  Query_Templ ate 

whi 1 e  more  values  in  Resul t_set  do 

Val ue_of_Predi cate  < —  next  value  from  Result_set 
Query  < —  Query  ! !  'A  '  ! !  Predicate 

end  whi 1 e 
el  se 

Query  < —  '  '  /*  Query  is  nil  */ 

Query_Templ ate  < —  Query_Templ ate  i i  ') ' 

Figure  14.  The  1-conjunction  Subroutine 
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Note,  in  Figure  14,  that  the  template  provided  to  the  1— 
conjunction  subroutine  is  identical  to  that  used  in  the  N- 
conjunction  subroutine.  An  additional  data  structure. 
Predicate  is  defined  as  (Attrname  Rel_opr  Value).  The  use 
of  this  additional  'template'  allows  us  to  extend  the  single 
con  juncti on , 

((FILE  =  Relname)  A  (Attrname  Rel _opr  Value)) 
to  the  mul tipi e-predi cate  si nq 1 e  conjunction, 

((FILE  =  Relname)  A  (Attrname  Rel_opr  Value)  A  .  .  . 

A  (Attrname  Rel_opr  Value)) 

The  number  of  predicates  generated  is  determined  by  the 
number  of  values  in  the  Result _set. 

B.  AN  ITERATIVE  STRUCTURE  FOR  CONTROLLING  THE  EXECUTION 
OF  N-LEVEL  SELECTIONS 

In  the  previous  section,  we  have  presented  algorithms 
for  building  the  QUERY  part  of  each  ABDL  RETRIEVE  generated 
in  the  translation  of  a  nested  SQL  SELECT.  We  now  consider 
the  process  of  controlling  the  execution  of  this  process.  An 
algorithmic  r epr esentat i on  of  a  simple  structure  for  the 
control  of  this  iterative  process  is  provided  in  Figure  15. 

This  N_1 evel _Sel ect  subroutine  is  called  by  the  Top-level 
process  of  the  interface  (described  in  Section  C) .  The 
parameters  passed  include  a  series  of  ABDL  RETRIEVE  requests 
(in  the  form  of  a  request  stack),  and  the  number,  n,  of  such 


requests.  We  recall,  from  Chapter  V,  that  the  innermost 
SELECT  level  is  viewed  as  the  nth-level.  Request  Stack  has 
the  ABDL  translation  of  the  nth-level  SELECT  on  top.  The 
lst-level  SELECT  i s  on  the  bottom.  The  stack  is  formed  in 
this  order  because  the  nth-level  request  is  the  only  request 
containing  a  fully  formed  queryjjart  (as  described  in 
Chapter  V).  Each  of  the  other  n-1  requests  requires  the 
Resultset  of  the  immediately  preceding  request  before  it 
can  be  sent  to  MDBS  for  processing. 


Subroutine  N_level _Select (Request_Stack ,n) 


/*  Request_Stack  has  the  ABDL  translation  of  the  */ 
/*  nth-level  SELECT  on  top.  The  lst-level  SELECT  */ 
/*  is  on  the  bottom.  Each  request  in  the  Stack  is  * / 
/*  composed  of  the  reserved  word  RETRIEVE,  Target _List,  */ 
/*  Set_Opr,  and  Query_Part.  The  Query_Part  of  the  */ 
/*  nth-level  SELECT  is  fully  formed.  The  Query _Part  */ 
/*  of  the  n-1  — >  lst-level  SELECTS  is  a  query  template  */ 
/*  having  the  form  */ 
/*  ((FILE  =  Relname)  A  (Attrname  Rel _opr  Value))  */ 
/*  with  a  blank  in  the  'Value'  position.  */ 


Current_Request  < —  Pop (Request_Stack ) 

Send ( Cur rent  _Request ) 

Reci eve (Resul t_Set  > 

for  i  < —  1  to  n-l  do 

Curr ent  Request  < —  Pop (Request _Stack > 

Cal  1  Query_Constructor (Quer y_Part , Resul t_Set , Set_Opr ) 
Send (Current_Request ) 

Recei ve (Resul t_Set ) 
end  for 

Di  spl  ay (Resul t_Set ) 
end  N  level  Sel ect 

Figure  15.  An  Iterative  Process  for  Controlling 
the  execution  of  N-level  SELECTS 


The  operation  of  the  N_1 evel _Sel ect  subroutine  is  as 
follows.  The  nth-level  request  is  popped  off  the  top  of 


Request 

_Stack  and 

becomes 

the 

Current_Request 

Th  i  s 

Current 

Request  is 

f orwarded 

to 

MDBS  through  the 

Send 

function.  Upon  completion  of  processing,  the  Result_set  is 
obtained  through  the  Recei ve  function.  The  remaining  n-1 
requests  are  popped  off  the  stack  and  processed  in  order. 
The  nth  and  succeeding  result  sets  are  incorporated  into 
each  request  through  a  call  to  Query-Constructor  (described 
in  Section  A).  The  Send  and  Receive  functions  are  used  on 
each  iteration  to  route  request/result  traffic  between 
N_1 evel _Sel ect  and  MDBS.  When  the  last  request  has 
completed  processing,  the  final  result  set  is  provided  to 
the  user  through  a  call  to  the  Pi  splay  subroutine.  Display 
presents  the  results  of  the  original  nested  SDL  SELECT  as  a 
resul t  rel ati on  (this  is  the  format  expected  by  a  SOL  user). 

C.  PROPOSED  SOFTWARE  STRUCTURE 

In  this  section,  we  present  a  software  structure  for  the 
implementation  of  nested  selections  in  our  proposed  SQL 
interface.  In  fact,  all  of  the  translations  heretofore 
introduced  in  this  thesis  and  in  Macy  CRef.  S3,  are 
supported  by  this  structure.  Therefore,  allowing  for 
possible  modifications  required  to  support  additional 
multiple  and  si ng 1 e-rel at i on  SOL  operations,  the  software 
structure  depicted  in  Figure  16  represents  the  overall 


software  structure  of  the  SQL  interface. 


As  depicted  in  Figure  16,  the  SQL  inter-face  is  comprised 


of  a  single 
■functions. 
Interface)  . 


top-level  process  with  multiple  subroutines  and 
The  top-level  process  is  called  SQLI  (SQL 
We  have  described  the  N  level  Select  subroutine 


Figure  16.  The  Proposed  Software  Structure 


group.  We  discuss  the  remaining  subroutines  as  we  explain 


the  functionality  of  SQLI. 


An  algorithm  for  SQLI  is 


The  operation  of  SQLI  is  an  follows.  Once  a  session  is 
initiated  from  the  user  terminal,  the  actions  depicted  in 
ALGORITHM  SQLI  are  repeated  until  session  termination.  The 
SQL  query  to  be  translated  into  the  equivalent  ABDL 
construct  is  obtained  through  a  call  to  the  subroutine 
Get_SQL_Query .  This  subroutine  polls  the  user  terminal  for 


ALGORITHM  SQLI 


Repeat 

CALL  Get _SQL_Query (Query ) 

CALL  SQLT (Query , Request _Stack , N , Error s ) 
i  f  N  =  0  then  /*  Syntax  Errors  */ 

CALL  Di spl ay (Query > 

CALL  Di spl ay (Errors) 

el se  i f  N  =  1  then  /*  Single  Request  */ 

Send (Pop ( Request _Stack ) ) 

Recei ve (Resul t_Set ) 

CALL  Di spl ay (Resul t_Set ) 
el  se  /*  N-level  Request  */' 

CALL  N_1 evel _Sel ect (Request_Stack , N) 
end  i  f 

End_af _sessi  on? 
unti 1  end_of _sessi  on 
end  ALGORITHM  SQLI 

Figure  17.  The  Top-level  Process  of  the  Interface,  SQLI 


input.  Note  that  when  a  query  is  obtained,  the  polling 
stops  until  the  result  relation  is  received  by  the  user  (or 
syntax  errors  are  displayed  for  the  user).  This  restriction 
is  placed  in  order  to  preclude  the  complexity  of  processing 
more  than  one  request  at  a  time.  (We  assume  that  several 
user  terminals  have  access  to  a  copy  of  SQLI,  and  that  each 
user  makes  a  request  and  waits  for  a  result  before  making 


another  request). 


The  query  obtained  by  the  call  to  Get_SOL_Ouer y  is 
passed  as  a  parameter  in  a  call  to  the  SQL  Translator 
(SQLT)  subroutine.  SQLT  parses  the  query,  recognizes  the 
query-type,  checks  for  syntax  errors,  and  translates  the  SQL 
query  to  the  appropriate  ABDL  request.  If  there  are  no 
syntax  errors,  SQLT  places  the  translated  requests  in  a 
stack  and  returns  this  Request_Stack ,  along  with  the  number, 
N,  of  requests  in  the  stack.  In  the  case  of  simple,  single- 
relation  operations,  Request_Stack  contains  one  request.  In 
the  case  of  a  nested  selection,  SQLT  first  parses  and 
translates  the  outermost  SELECT  placing  the  resultant 
RETRIEVE  request  on  the  stack.  As  previously  discussed,  the 
request  contains  a  query-tempi  ate.  (Recall  that  only  the 
nth-level,  or  innermost,  request  is  fully  formed).  If  there 
are  syntax  errors,  SQLT  returns  a  value  of  zero  for  N.  The 
errors  are  also  returned. 

If  the  number  of  requests  in  Request_Stack  is  zero  (N  = 
0) ,  then  SQLT  has  detected  syntax  errors.  In  this  case, 
SQL  I  makes  two  calls  to  the  Display  subroutine  in  order  to 
provide  the  user  a  display  of  the  query  and  of  the  errors 
detected.  If  the  number  of  requests  in  Request _Stack  is  one 
(N  =  1) ,  then  the  single  request  is  popped  off  the  stack  and 
forwarded,  via  the  Send  function,  to  MDBS  for  processing. 
The  Result_set  is  obtained  through  the  Recei ve  function. 
The  result  relation  is  provided  to  the  user  through  a  call 
to  the  Display  subroutine.  If  the  number  of  requests  in 
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Request_Stack  is  greater  than  one,  then  N_1 evel _Sel ect  is 
called.  The  subsequent  processing  is  explained  in  Section 

B. 

As  previously  discussed,  we  propose  that  the  SDL 
interface  be  implemented  such  that  SOLI  and  its  subroutines 
are  resident  on  a  host  computer.  This  precludes  the  need  to 
place  an  additional  workload  on  the  MDBS  Controller.  In 
effect,  MDBS  is  "unaware"  that  the  user  is  making  database 
requests  in  SOL,  and  the  user  need  only  know  what 
information  is  desired  and  how  to  form  the  request  in  the 
syntax  of  SDL.  The  logical  structure  of  the  system  is 
depicted  in  Figure  18. 


i  n 

host 

computer 


MDBS 


i  n  the 

backends  and 
their  controller 


Figure  18. 


The  Logical  Structure  of  the  System 
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VII.  ADDITIONAL  SQL-TO— ABDL  TRANSLATIONS 

We  have  described  single-relation  set  membership  and 
multiple-relation  nested  SQL  SELECT  operations.  For  each 
SQL  operation,  we  have  developed  the  appropriate  ABDL 
translation.  In  Chapter  VI,  we  have  proposed  a  software 
structure  to  -facilitate  the  implementation  o-f  these 
translations,  in  addition  to  the  simple,  single-relation 
translations  which  Macy  CRef.  81  has  provided.  In  this 
chapter,  we  investigate  other  selected  si ngl e— rel at i on  and 
mul ti pi e— rel at i on  SQL  operations.  Inclusion  of  these  highly 
desirable  options  in  the  SQL  set  operations  supported  by  the 
interface  further  demonstrates  the  power  of  ABDL  to  support 
relational  operations. 

As  in  previous  chapters,  the  approach  of  this  chapter  is 
to  describe  each  SQL  operation  and  then  determine  which  ABDL 
constructs  can  be  used  to  support  the  operation.  As  each 
translation  is  developed,  we  show  graphically, 
al gor i thmi cal  1 y ,  and  through  text  how  the  software  structure 
of  the  interface  (described  in  Chapter  VI)  must  evolve  in 
order  to  accomodate  the  additional  operations.  The  single¬ 
relation  operations  are  presented  in  Section  A,  and  the 
multiple-relation  operations  are  presented  in  Section  B.  In 


Section  C,  we  present  the  modified  software  structure  of  the 


A.  SELECTED  SINGLE-RELATION  OPERATIONS 

The  single-relation  operations  selected  for  discussion 
in  this  section  include:  updating  multiple  attributes  in  a 
single  record;  retrieving  groups  of  attributes  which  satisfy 
a  group  condition;  retrieving  computed  values;  providing 
format  options;  retrieving  ordered  attributes  (SORT);  and 
eliminating  duplicates  (PROJECTION).  These  operations  are 
commonly  supported  in  commercial  relational  database  systems 
utilizing  the  SQL  language.  A  SQL— trained  user  of  the 
interface  proposed  in  this  thesis  would  expect  to  be  able  to 
utilize  familiar  SQL  constructs  to  perform  these  operations. 
We  address  the  SQL-TO— ABDL  translations  in  the  following 
subsections. 

1 •  Updating  Multiple— Attributes 

All  data  1 anguages  provide  a  data  update  capability. 
Of  interest  here  is  the  SQL  construct  for  update.  This 
construct  allows  the  user  to  change  the  values  of  any  number 
of  attributes  stored  in  the  record  by  issuing  a  single 
query.  This  capability  is  both  convenient  and  efficient. 
The  following  example  depicts  the  updating  of  multiple- 
attributes  (fields)  in  a  single  record.  If  we  wish  to 
change  the  color  of  part  P2  to  yellow,  increase  its  weight 
by  5,  and  set  its  city  to  Normandy,  we  may  use  the  following 


SQL  query: 


UPDATE 


P 


SET  COLOR  =  'Yellow', 

WEIGHT  =  WEIGHT  +  5, 

CITY  =  'Normandy' 

WHERE  P#  =  ' P2 ' 

In  this  example,  we  are  updating  the  attributes  COLOR, 
WEIGHT,  and  CITY  in  a  single  record  with  primary  key,  P2. 
The  record  is  contained  in  the  Parts  (P)  relation.  Note 
that  any  reference  to  an  attribute  on  the  right-hand  side  of 
an  equals  sign  refers  to  the  value  of  that  attribute  pr i or 
to  updating. 

In  studying  the  SQL  example  above,  we  note  that 
there  are  three  cases  to  consider  depending  on  the 

attributes  listed  in  the  SET  and  WHERE  clauses.  We  refer  to 
these  as  case-0,  case-1,  and  case-2  updates.  To  facilitate 
the  following  explanation,  let  S  be  the  set  of  distinct 
attribute  names  listed  in  the  SET  clause,  and  W  be  the  set 
of  distinct  attribute  names  listed  in  the  WHERE  clause.  In 
case-0  updates  (e.g.,  the  above  example),  no  attribute  is 
listed  in  both  the  SET  and  WHERE  clauses  (i.e.  ,  S  Pi  W  =  0) . 
In  case-1  updates .  one  attribute  is  listed  in  both  clauses 
(i.e.,  cardinality(S  D  W)  =  1).  In  case— 2  updates .  mul ti pi e 
attributes  are  listed  in  both  clauses 

(i.e.  ,  cardinal ity(S  ■  '  W)  >  1).  A  case- 1  modi f i cati on  of 
our  example  is  as  follows: 


UPDATE  P 

SET  COLOR  =  'Yellow', 

WEIGHT  =  WEIGHT  +  5, 

CITY  =  'Normandy' 

WHERE  (P#  =  ' P2 ' )  AND  (CITY  =  'Paris  ) 

Note,  CITY  is  in  both  S  and  W,  and  the  cardinality  o-f 
(S  O  W)  is  1.  A  case-2  modification  o-f  our  original 

example  is  as  follows: 

UPDATE  P 

SET  COLOR  =  'Yellow', 

WEIGHT  =  WEIGHT  +  5, 

CITY  =  'Normandy' 

WHERE  (P#  =  'P2 ' )  AND  (CITY  =  Paris') 

AND  (COLOR  =  GREEN) 

Note,  CITY  and  COLOR  are  in  both  S  and  W,  and 
cardi nal i ty (S  f)  W)  >1.  The  SQL-to-ABDL  translations  of  the 
three  cases  of  multiple— attribute  update  are  described  in 
the  following  subsection. 

a.  The  translation  to  ABDL 

ABDL  does  not  provide  a  si ngl e— request  construct 
which  updates  more  than  one  attribute  in  a  record.  We  must 
translate  the  SQL  UPDATE  into  multiple  ABDL  UPDATES.  Case-0 
SQL  UPDATE  queries  can  be  translated  directly  to  multiple 
ABDL  UPDATE  requests.  The  order  in  which  these  requests  are 


processed  is 


immaterial . 


The  case-0  example 


above 


translates  to  the  following  three  independent  ABDL  UPDATE 
requests: 


UPDATE 

( (FILE  =  P) 

A 

(P# 

=  P2)  > 

(COLOR 

=  Yellow) 

UPDATE 

< (FILE  =  P) 

A 

(P# 

=  P2>  ) 

(WEIGHT 

=  WEIGHT  +  5) 

UPDATE 

( (FILE  =  P) 

A 

(P# 

=  P2>  ) 

(CITY  = 

Normandy) 

Our  case-1  example  translates  to  the  same  three 
UPDATE  requests,  however,  the  presence  of  the  CITY  attribute 
in  both  the  WHERE  and  SET  clauses  effects  the  structure  of 
the  translation-  The  order  of  request  processing  now 
becomes  important.  For  example,  if  CITY  is  updated  first, 
the  condition  (  (P#  =  'P2')  AND  (CITY  =  'Paris'))  is  no 
longer  satisfied  when  a  subsequent  attempt  is  made  to 
process  the  COLOR  and  WEIGHT  UPDATE  requests.  ABDL  provides 
a  construct  called  a  Transacti on  which  specifies  the  order 
in  which  a  series  of  requests  must  be  processed.  Therefore, 
the  case-1  translation  becomes 

BEGIN  Transaction 


UPDATE 

( (FILE  =  P> 

A 

<P# 

=  P2>  ) 

(COLOR  > 

=  Yellow) 

UPDATE 

( (FILE  =  P) 

A 

(P# 

=  P2>  ) 

(WEIGHT 

=  WEIGHT  +  5) 

UPDATE 

( (FILE  =  P> 

A 

(P# 

=  P2)  ) 

(CITY  = 

Normandy) 

END  Transaction 

Requests  within  a  transaction  are  processed  in  the  same 
order  as  they  are  specified.  Therefore,  we  can  obtain  a 


correct  result. 


The  case-2  example  also  translates  to  a  series 
of  three  ABDL  requests.  However,  the  translation  is  more 
complex.  In  this  case,  multiple  attributes  specified  in  the 
WHERE  clause  are  also  listed  in  the  SET  clause.  When  the 
first  of  these  attributes  is  updated,  all  subsequent 
attempts  to  update  the  remaining  attributes  will  fail. 
Since  the  WHERE  condition  is  no  longer  satisfiable,  the 
record  can  not  be  found.  The  following  sequence  of  ABDL 
requests  accomplishes  the  requested  update.  (Note  that  the 


ABDL  UPDATE  construct  is  not  used). 


RETRIEVE  ((FILE  =  P)  A  (P#  =  P2) )  <P# , PNAME , COLOR , WE IGHT , 

CITY> 

DELETE  ((FILE  =  P)  A  (P#  =  P2>  A  (PNAME  =  Bolt)  A 
(COLOR  =  Green)  A  (WEIGHT  =17)  A 
(CITY  =  Paris) ) 

INSERT  (CFILE  =  P>,<P#  =  P2>,<PNAME  =  Bolt>, 

< COLOR  =  Yel  low>,<WEIGHT  =  22>,<CITY  =  Normandy  .-) 


b.  A  proposed  Software  Structure 

In  order  to  implement  multiple-attribute 
updates,  we  must  augment  the  functionality  of  the  software 
structure  (SQLI)  which  we  have  developed  in  Chapter  VI.  We 
specify  an  additional  parameter.  Request  Type.  to  be 
returned  by  SQLT.  When  the  value  of  Request _Type  is 
' CaseO_update ' ,  the  subroutine  CaseO_update  is  called.  In 
this  case,  the  multiple  ABDL  RETRIEVE  requests  are  simply 
removed  from  Request_Stack  and  forwarded  to  MDBS  for 
processing.  As  previously  stated,  the  order  of  processing 


does  not  effect  the  result. 


When  all  updates  are  complete, 


the  user  is  so  informed.  When  the  value  of  Request_Type  is 
'Casel_update' ,  the  subroutine,  Casel  update  is  called. 
When  the  value  of  Request_Type  is  ' Case2_update ' , the 
subroutine,  Case2  update  is  called.  The  Casel_update  and 
Case2_update  subroutines  are  presented  in  Figures  19  and  20, 
respect i vel y . 


Subroutine  Casel_update  ( Request _Stack. ,  Resul  t_Set ) 


/*  Transact i on_Request :  */ 
/*  is  a  template  with  the  Reserved  word  BOT  */ 
/*  followed  by  multiple  blank  lines  (to  be  used  */ 
/*  by  the  series  of  requests)  and  the  Reserved  */ 
/*  word  EOT.  */ 


whi 1 e  NOT  EMPTY (Request_Stack )  do 
Pop (Request _Stack ) 

Fill  in  blank  lines  of  Transaction _Request  with 
requests  from  Request_Stack 
end  while 

Send (TransactionRequest ) 

Receive (Resul t_Set)  /*  Resul t_Set  returned  to  */ 

/*  calling  routine  */ 


end  Casel_update 

Figure  19.  Subroutine  Casel _Update 


The  Casel_Update  subroutine  builds  a  transaction 
of  update  requests  for  MDBS  processing.  The  subroutine  is 
provided  the  parameter  Request_Stack  which  contains  multiple 
UPDATE  requests  stacked  such  that  the  request  on  the  bottom 
of  the  stack  is  the  request  which  must  be  processed  last. 


Subroutine  Casel_Update  sends  the  request  transaction  to 


MDBS,  Receives  the  Result_Set,  and  returns  the  Result_Set  to 
the  calling  routine. 


Subroutine  Case2_update (Request _Stack , Resul t_Set ) 


/*  Insert_Template:  * / 

/*  is  the  INSERT  request  with  values  -for  the  */ 

/*  attri butes— to-be— updated  and  blanks  -for  the  */ 

/*  attributes  whose  values  are  obtained  by  the  */ 

/*  RETRIEVE  request.  */ 

Send (Pop (Request _Stack ) )  /*  RETRIEVE  request  */ 

Recei ve (Resul t_Set ) 

Send (Pop (Request_Stack> >  /*  DELETE  the  record  */ 

Recei ve (Resul t_Set)  /*  deletion  is  complete  */ 

Whi 1 e  there  are  records  to  update  do 

Insert_Templ ate  < —  /*  -fill  in  blanks  with  retrieved  */ 

/*  attribute  values  */ 

Insert_Request  < —  /*  form  the  INSERT  request  from  */ 

/*  the  record  and  Insert_Templ ate  */ 

Send ( Insert_Request ) 
end  while 

Recei ve (Resul t_Set)  /*  INSERT  is  complete  */ 

end  Case2_update 


Figure  20.  Subroutine  Case2_update 


The  Case2_Update  subroutine  controls  the 
execution  of  the  RETRIEVE— DELETE-INSERT  series  of  requests. 


The 

RETRIEVE  obtains  a  copy  of 

the 

appropr i ate 

record (s)  . 

The 

DELETE  deletes  the  original 

record (s)  in 

the 

database. 

The 

INSERT  re— inserts  the  record(s) 

with  all 

the 

modi f i ed 

attri 

bute  values. 

2.  Retri evino  Qual i f i ed  Groups 

Both  SQL  and  ABDL  provide  an  option  whereby 


retrieved  attributes  may  be  grouped. 


For  example. 


i  f  we 


wish  to  obtain  the  part  number  and  the  total  quantity  -for 
each  part  supplied,  we  may  utilize  the  following  SELECT 
construct : 

SELECT  P# , SUM (QTY) 

FROM  SP 
GROUP  BY  P# 

The  result  relation  is: 


Note  that  "...each  expression  in  the  SELECT  clause  must  be 
single- valued  for  each  group;  that  is,  it  can  be  either  the 
GROUP_BY  field  itself,  or  a  function  such  as  SUM  that 
operates  on  all  values  of  a  given  field  within  a  group  and 
reduces  those  values  to  a  single  value."  CRef.  9] 

The  above  SQL  operation  is  directly  supported  by  the 
software  structure  of  Chapter  VI.  Using  the  SELECT— to- 
RETRIEVE  mapping  which  we  have  described  in  Chapter  III,  the 
equivalent  ABDL  construct  is: 

RETRIEVE  (FILE  =  SP) < PH, SUM (QTY) >  BY  P# 

SQL  provides  a  further  option  for  use  with  grouped 
attributes.  Once  the  rows  of  a  table  are  grouped  by  a 
selected  attribute,  groups  not  satisfying  a  specified 


condition  can  be  eliminated  through  the  use  of  the  HAVING 
operator.  The  following  comprehensive  example  clarifies  the 
use  of  the  'GROUP  BY  with  HAVING'  option.  If  we  wish  to 
obtain  the  part  number  and  the  maximum  quantity  of  the  part 
supplied  for  all  parts  such  that  the  total  quantity  supplied 
is  greater  than  300  (excluding  from  the  total  all  shipments 
for  which  the  quantity  is  less  than  or  equal  to  200),  we  may 
use  the  following  query: 

SELECT  P#, MAX (QTY) 

FROM  SP 
WHERE  QTY  >  200 

GROUP  BY  P# 

HAVING  SUM (QTY)  >  300 

We  can  imagine  the  result  relation  I  P#  j 


P# 

PI 

300 

P2 

400 

P3 

400 

P5 

400 

being  formed  as  fallows.  A  copy  is  made  of  table  SP  (FROM). 
The  rows  not  satisfying  "QTY  >  200"  are  eliminated  (WHERE). 
The  remaining  rows  are  then  grouped  by  P#  (GROUP  BY) .  The 
newly  formed  groups  are  checked  against  the  predicate 
"SUM(QTY)  >  300".  Those  not  satisfying  the  condition  are 
eliminated  (HAVING).  Finally,  part  numbers  and  maximum 
quantities  are  extracted  from  the  remaining  groups  (SELECT). 


a.  The  Translation  to  ABDL 

As  previously  discussed,  ABDL  provides  a 
construct  for  the  retrieval  of  data  which  is  grouped  by  a 
selected  attribute.  In  the  comprehensive  SQL  example  above, 
the  use  o-f  the  HAVING  operator  specifies  a  further 
qualification  on  the  groups.  In  this  example,  the  groups 
whose  total  quantity  supplied  is  less  than  or  equal  to  300 
are  to  be  eliminated.  ABDL  does  not  provide  a  facility  for 
checking  this  group  condition.  This  condition  must  be 
checked  in  the  interface.  The  SQL  query  is  translated  to 
the  ABDL  request 

RETRIEVE  < (FILE  =  SP)  A  (QTY  >  200))  <P# , MAX (QTY) , SUM (QTY ) > 

BY  P# 


which  we  imagine  returns  the  fallowing  table: 


p# 

MAX (QTY) 

SUM (QTY) 

PI 

300 

600 

P2 

400 

400 

P3 

400 

400 

P4 

300 

300 

P5 

400 

400 

Software  in  the  interface  then  checks  the  HAVING  condition 
"SUM(QTY)  >  300".  This  eliminates  the  grouping  for  part  P4. 
The  remaining  part  numbers  and  maximum  quantities  are 


returned  to  the  user. 


b. 


A  Proposed  Software  Structure 


When  SQLT  returns  the  value,  ' Group_by_havi ng 
for  the  parameter,  Request_Type ,  we  assume  that  the  HAVING 
condition  is  also  made  available  to  the  Broup-By-Havi ng 
subroutine.  (We  make  a  similar  assumption  for  other 
Request _Types )  .  The  subroutine  sends  the  request,  recei /es 
the  result  set,  checks  the  HAVINS  condition,  and  returns 
only  those  tuples  satisfying  the  having  condition  to  the 
user.  Figure  21  depicts  this  operation. 

Subroutine  Sroup-By— Havi ng  ( Request __Stack.  ,HAVING_condi  ti  on  , 

Resul t_Set ) 

Send (Pop (Request_Stack ) 

Recei ve (Resul  t_Set ) 

Eliminate  groups  not  satisfying  HAVING  condition 
end  Group_By_Havi ng 

Figure  21.  Subroutine  Gr oup _By _Ha v i ng 

3.  Retr i evi ng  Computed  Val ues 

The  concept  of  retrieving  computed  values  is  simple, 
yet  it  typifies  the  important  options  that  database 
management  system  designers  are  providing  in  order  to  ensure 
user— f r i endl i ness  and  user-flexibility.  This  option  supports 
the  inclusion  of  arithmetic  expressions  involving  fields  as 
well  as  simple  field-names.  For  example,  the  user  should  be 
able  to  specify  uni ts-of -measure  for  numerical  results.  SQL 
supports  this  concept.  If  we  wish  to  obtain  the  part  number 
and  the  weight  of  the  part  in  grams  (given  in  table  P  ir> 


pounds) ,  we  may  use  the  following  query: 


SELECT  P# , WE I SHT  *  454 
FROM  P 


The  result  relation  is: 


p# 

PI 

5448 

P2 

7718 

P3 

7718 

P4 

6356 

F'5 

5448 

ta2h- 

a.  The  Translation  to  ABDL 

In  this  translation,  the  ABDL  request  retrieves 
the  indicated  attributes  leaving  any  computation  to  be 
accomplished  in  the  interface.  For  the  example  above,  the 
ABDL  translation  is 

RETRIEVE  <FILE=  P)  <P#,WEIGHT> 

The  specified  arithmetic  operation  is  performed  by  interface 
software  on  the  retrieved  values  for  WEIGHT  (i.e.  ,  WEIGHT  * 
454)  prior  to  returning  the  final  result  relation  to  the 
user.  The  software  required  is  a  simple  interpreter  for 
evaluating  arithmetic  expressions. 

b.  A  Proposed  Software  Structure 

An  Expressi on_Eval uator  subroutine  can  be  used 
to  accomplish  the  arithmetic  operations  specified  in  the  SQL 
query.  The  subroutine  simply  utilizes  the  appropriate 
function  (e.g.,  Mul t , Add , Sub , Di v)  to  perform  the  operation. 


4.  Provi ding  Format  Qpt i ons 

Often,  the  information  retrieved  from  a  database  is 
intended  for  use  in  published  reports.  The  availability  of 
formatting  options  can  make  generating  these  reports 
simpler.  For  example,  while  it  is  prudent  to  save  disk 
space  by  storing  the  names  of  suppliers  as  values  for  an 
attribute-name  such  as  SNAME ,  an  end-user  unfamiliar  with 
the  database  is  psychol ogi cal  1 y  more  comfortable  with  a 
column  heading  such  as  SUPPLIERS.  In  SQL  queries,  the 
desired  format  is  indicated  in  the  SELECT  clause.  For 
example,  if  we  wish  to  obtain  the  names  of  all  suppliers,  we 
may  use  the  fallowing  query: 


SELECT  SNAME  SUPPLIERS 


FROM 


The  result  relation  is: 


SUPPLIERS 


Smi  th 
Jones 
B1  ake 
Cl  ark 


Note  that  the  column  heading  is  SUPPLIERS  rather  than  the 
field  name,  SNAME. 

a.  The  Translation  to  ABDL 

This  translation  is  similar  to  that  presented  in 
Subsection  2  above.  Information,  returned  from  MDBS,  is 
modified  by  the  interface  software.  The  SQL  SELECT  query  is 


translated  to  the  ABDL  request 
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RETRIEVE  (FILE  =  S>  <SNAME> 

The  results  o-f  this  request  are  modified  by  the  SQL 
interface  (SQLI)  prior  to  returning  the  final  result 
relation  to  the  user.  In  this  case,  the  column  heading, 
SNAME,  is  changed  to  the  new  heading,  SUPPLIERS, 
b.  A  Proposed  Software  Structure 

Format  options  can  be  provided  in  the  Display 
subroutine.  Any  change  in  the  form  of  the  table  heading  can 
be  passed  at  the  time  of  the  call  to  Display. 

S.  The  Retrieval  wi th  Drder i ng  (SORT) 

Generally,  the  result  of  a  SELECT  operation  is  not 
guaranteed  to  be  in  any  particular  order.  Ordering  (SORT)  is 
normally  not  accomplished  in  SQL  queries  unless  specifically 
requested  by  the  user.  This  operation  may  be  costly,  and 
the  additional  expense  is  often  unwarranted.  In  SQL,  the 
user  may  specify  ordering  through  the  use  of  the  ORDER__BY 
operator.  As  an  example,  if  we  wish  to  obtain  supplier — 
numbers  for  all  suppliers  providing  shipments,  such  that  the 
result  is  ordered  by  suppl i er— number ,  we  may  use  the 
following  query: 


SELECT  UNIQUE  S# 
FROM  SP 


ORDER 


BY  S# 


The  result  relation  is: 


a.  The  Translation  to  ABDL 

In  the  translation  of  the  above  SQL  query,  we 
assume  an  ordering  capability  within  MDBS.  The  development 
o-f  this  capability  is  the  goal  o-f  a  current  thesis  by  Muldur 
CRef  151.  The  ABDL  request 


RETRIEVE  (FILE  =  SP)  <S#>  ORDER  BY  S# 


returns  all  supplier  numbers  (ordered  by  increasing  supplier 
numbers)  contained  in  the  SP  -file  (including  duplicates), 
b.  A  Proposed  Software  Structure 

We  assume  that  the  ordering  o-f  selected 
attributes  is  directly  supported  by  MDBS.  Therefore,  no 
augmentation  of  SQL I  is  required. 

6.  An.  El  imination  of  Dupl  i cates  (PROJECTION) 

The  results  of  a  SELECT  operation  may  contain 
duplicates.  The  elimination  of  duplicates  (PROJECTION),  as 
in  the  case  of  retrieval  with  ordering  (SORT),  is  normally 
not  accomplished  in  SQL  queries  unless  specifically 
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not 


requested . 


Agai n , 


the  cost  is  high  and  often  unwarranted. 


An  exception  to  this  rule  is  that  duplicate  rows  are 


automatically  eliminated  in  UNION  operations.  (UNION 


operations  are  described  in  Section  EO 


In  SQL,  the  elimination  of  duplicates  may  be 


specified  through  the  use  of  the  UNIQUE  operator.  As  an 


example,  if  we  wish  to  obtain  supplier-numbers  for  all 


suppliers  providing  shipments  such  that  no  supplier — number 


is  listed  more  than  once,  and  the  result  is  ordered  by 


suppl i er— number ,  we  may  use  the  following  query: 


SELECT  UNIQUE  S# 


FROM  SP 


ORDER  BY  S# 


The  result  relation  is: 


This  example  is  a  modification  of  the  example  presented  in 


Subsection  5.  Note  that  duplicate  suppl ier— numbers  are 


el i mi nated. 


a.  The  Translation  to  ABDL 


The  ABDL  translation  for  the  above  SQL  query  is 


identical  to  the  translation  for  our  Subsection  5  example. 


Again,  the  ABDL  request 


RETRIEVE  (FILE  =  SP)  <S#>  ORDER  BY  S# 
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returns  all  supplier-numbers  (ordered  by  increasing 
supplier-numbers)  contained  in  the  SP  -file  (including 
duplicates).  Since  UNIQUE  is  specified  in  the  SELECT  clause 
of  the  SQL  query,  SQLI  must  check  the  ordered  rows 
eliminating  duplicate  values  for  the  S#  attribute  prior  to 
forwarding  the  result  relation  to  the  user.  If  our  example 
is  modified  such  that  the  ORDER  BY  clause  is  omitted,  we  may 
facilitate  the  elimination  of  duplicates  by  "forcing"  a  SORT 
of  the  selected  attributes.  That  is,  the  ABDL  RETRIEVE 
request  is  written  to  include  an  ORDER  BY  specification, 
b.  A  Proposed  Software  Structure 

When  UNIQUE  is  specified  in  the  SQL  query,  the 
Result _Set  from  MDBS  is  passed  in  a  call  to  a 
Dupl icate_El iminator  subroutine.  This  subroutine  scans  and 
compares  adjacent  members  of  an  ordered  Result_Set 
eliminating  duplicate  members.  We  assume  that  the 
Result_Set  is  always  ordered  prior  to  being  passed  to 
Dupl i cate_El i mi nator .  The  ordering  is  either  user— speci f i ed 
or  "forced"  in  the  SQLT  translation. 

B.  SELECTED  MULTIPLE-RELATION  OPERATIONS 

In  this  section,  we  discuss  two  additional  multiple- 
relation  operations  which  are  supported  by  SCIL:  retrieval 

using  the  UNION  operator  and  retrieval  specifying  JOIN 
operations.  These  two  operations  and  the  nested  SELECT 
(described  in  Chapter  V)  give  SQL  much  of  its  power  and 
flexibility.  The  availability  of  query  constructs  which 


allow  access  to  related  data  in  multiple  tables  greatly 


enhances  the  ease  with  which  a  user  can  obtain  the  desired 
information  from  the  database.  We  investigate  UNION  and 
JOIN  operations  in  the  following  subsections. 

1.  The  Retri eval  Usi no  UNION 

From  set  theory,  we  recal 1  that  the  UNION  of  sets  A 
and  B  (i.e. ,  A  UNION  B)  is  the  set  of  all  objects  x  such 
that  x  is  a  member  of  A  or  x  is  a  member  of  B.  The  formal 
predicate  logic  definition  of  A  UNION  B  is: 

Vx  C  <x  A)  V  (x  B)  1 

In  SQL,  the  UNION  operator  is  used  in  a  query 
comprised  of  mul tiple-SELECT  constructs.  As  an  example,  if 
we  wish  to  obtain  numbers  for  parts  that  either  weigh  more 
than  16  pounds  or  are  currently  supplied  by  supplier  S2  (or 
both),  we  may  use  the  following  query: 

SELECT  P# 

FROM  P 

WHERE  WEIGHT  >  16 

UNION 

SELECT  P# 

FROM  SP 


00 


WHERE 


S# 


'  S2  ' 


The  result  relation  is: 


P# 

P2 
P3 
P6 
PI 

From  the  sample  database  of  Chapter  I,  we  can  see  that  parts 
P2,  P3,  and  P6  weigh  more  than  16  pounds  (x  £|A>.  Part  PI 
weighs  less  than  16  pounds,  however,  PI  is  currently 
supplied  by  supplier  S2  (x0B).  Part  P2  weighs  more  than  16 
|  pounds  and  is  supplied  by  supplier  S2  ((x0A)  A  (x  0  B)  )  . 

Note  that  duplicate  rows  are  eliminated  from  the  result  of  a 
UNION  operation. 

a.  The  Translation  to  ABDL 

In  the  SQL  query  above,  each  SELECT  construct 
translates  into  an  equivalent  ABDL  RETRIEVE  request.  In 
|  this  example,  the  two  ABDL  requests 

RETRIEVE  <FILE  -  P>  A  (WEIGHT  >  16)  <P#>  ORDER  BY  P# 
RETRIEVE  (FILE  =  SP)  A  (S#  =  S2)  <P#>  ORDER  BY  P# 

I 

are  processed  concurrently.  The  results  are  combined  in 
SQLI,  where  duplicate  rows  are  eliminated.  The  remaining 
rows  are  forwarded  to  the  user. 

b.  A  Proposed  Software  Structure 

When  the  value  of  Request_Type  is  UNION,  the 
translation  and  processing  are  as  follows.  An  MDBS  SORT  is 
specified  .  in  the  ABDL  translation.  A  subroutine  called 
UNION  pops  all  ABDL  RETRIEVE  requests  off  of  Request  Stack 
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and  -forwards  them  to  MDBS  for  concurrent  processing. 


The 


ordered  result  sets  are  merged  (through  the  use  of  a 
standard  merge  function) ,  and  then  passed  to 
Dupl i cate_El  i mi nator .  Finally,  the  uniquely  selected 
results  of  the  UNION  operation  are  returned  to  SQL  I  for 
display  to  the  user.  Subroutine  UNION  is  presented  in 
Figure  22. 


Subroutine  UNION (Request _Stack , Resul t_Set) 

while  NOT  EMPTY (Request _Stack )  do 
Send (Pop ( Request _St ac k ) 
end  whi 1 e 

Recei ve (Resul t_Set 1 ) 

Recei ve (Resul t_Set2) 

Merge (Resul t_Set 1 , Resul t_Set2) 

CALL  Dupl icate_El i mi nator (Resul t_Set) 

end  UNION 

Figure  22.  Subroutine  UNION 

2.  The  Retrieval  Speci f yi no  Joi n  Operations 

Join  operations  are  character i sti c  of  data  languages 
intended  for  use  with  relational  databases.  SQL  provides 
the  capability  to  specify  implicit  join,  equality  join,  and 
inequality  join  operations.  In  an  implicit  ioi n .  attribute- 
values  in  multiple  tables  are  compared,  however,  the  values 
returned  to  the  user  are  taken  from  only  one  table. 
Implicit  joins  can  be  formed  through  the  use  of  the  nested 
SQL  SELECT  constructs  which  we  have  described  in  Chapter  V. 
In  the  nested  SELECT,  multiple  tables  are  accessed  and  the 


values  of  selected  attributes  are  compared.  We  note  that 
only  values  -from  the  outermost  SELECT  are  returned  in  the 
final  result  set.  This  operation  results  in  the  formation 
of  an  implicit  join. 

Equal i tv  joi n  and  i n equal i tv  joi n  operations  are 
specified  by  referencing  multiple  tables  in  a  single  SELECT 
query.  As  an  example  of  an  equality  join,  if  for  each  part 
supplied  we  wish  to  obtain  part  numbers  and  names  of  all 
cities  supplying  the  part,  we  may  use  the  following  query: 


SELECT  UNIQUE  P#,CITY 
FROM  SP , S 


WHERE  SP.S#  =  S.S# 


The  result  relation  is: 


>#  CITY 

*1  London 
=•1  Paris 
y 2  London 
>2  Paris 
53  London 
J4  London 
*5  London 
s6  London 


Note  that  table— names  may  be  used  as  qualifiers  in  the 
SELECT  and  WHERE  clauses  in  order  to  resolve  ambiguities  or 
to  ensure  clarity.  For  example,  the  SELECT  clause  may  be 
equivalently  written 


SELECT  UNIQUE  SP.P#,S.CITY 


Although  there  are  optimization  techniques  which 
-facilitate  a  more  efficient  implementation,  we  can  visualize 
the  join  operation  as  follows.  First  the  Cartesian  product 
of  SP  and  S  is  formed.  Then,  rows  not  satisfying  the 
condition  SP.S#  =  S.S#  are  eliminated.  Next,  columns  P#  and 
CITY  are  projected  from  the  remaining  rows.  Finally,  since 
the  operator  UNIQUE  is  used,  all  duplicate  rows  are  removed 
before  the  result  relation  is  returned  to  the  user.  (For  an 
indepth  discussion  of  the  efficiency  and  optimization 
considerations  of  implementing  join  operations,  the  reader 
is  referred  to  Demur ji an  CRef.  13). 

a.  The  Translation  to  ABDL 

The  attri bute— based  data  language,  as 

implemented  in  MDBS,  does  not  provide  a  join  capability. 
Muldur  CRef.  153  is  currently  investigating  the  practicality 
of  i ncorpor ati ng  join  operations  within  MDBS.  If  we  assume 
that  the  functionality  of  MDBS  is  augmented  to  support  the 
equality  join  and  inequality  join  operations,  we  might  use 
the  following  translation  for  the  equality  join  (as 
discussed  in  Demur ji an  CRef.  13).  The  general  form  of  a 
simple,  two-way  equality  join  expressed  in  the  syntax  of  SQL 
i  s 

SELECT  sel _expr _1  i st 

FROM  relation_namel ,  rel ati on_name2 

WHERE  rel ation_namel . attribute  =  rel at i on_name2. attri bute 
AND  qualification 
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The  general  -form  a f  the  ABDL  translation  is 

RETRIEVE  (attr ibute_l i st_l )  (query_l) 

CONNECT  ON  < attr i bute_l ,  attribute_2) 

(attribute_l i st_2)  (query_2> 

The  sel _expr_l i st  of  the  SQL  SELECT  is  divided  into  a  target 
list  consisting  of  attributes  from  rel ati on_namel  and  a 
target  list  consisting  of  attributes  from  rel at i on_name2. 
The  qualification  of  the  SQL  SELECT  is  likewise  partitioned. 
The  attributes  named  in  the  equality  predicate  become  the 
object  of  the  CONNECT  ON  clause  in  the  ABDL  request. 

Following  this  general  form,  the  translation  for  the 

equality  join  example  of  the  preceding  subsection  is 

RETRIEVE  <  (S#,P#>  (FILE  =  SP)  > 

CONNECT  ON  (SP.S#,  S.S#> 

<  (S#,CITY>  (FILE  =  S)  > 

b.  A  Proposed  Software  Structure 

As  stated  previously,  we  assume  a  join 

capability  for  MDBS.  Therefore,  no  augmentation  of  SQLI  is 
required. 

C.  THE  MODIFIED  SOFTWARE  STRUCTURE  OF  THE  SQL  INTERFACE 

In  this  section,  we  present  the  modified  software 

structure  of  SQLI.  We  modify  the  structure  which  we  have 
presented  in  Chapter  VI  in  order  to  facilitate  the 
implementation  of  the  additional  operations  described  in 


this  chapter.  The  modified  version  of  the  top-level 
process,  SQL  I ,  is  shown  in  Figure  23.  Note,  we  have 
simplified  this  algorithm  through  the  use  of  the 
Request_Control  subroutine.  The  f unctional i ty  of  this 
subroutine  is  presented  in  Figure  24.  The  purpose  of 
Request_Contr ol  is  to  provide  overall  control  of  request 
processing  for  the  interface.  A  high-level  view  of  the 
modified  software  structure  is  shown  in  Figure  25,  and  the 
relationship  between  Subroutine  Request_Control  and  its 
subordinate  group  of  subroutines  is  depicted  in  Figure  26. 


ALGORITHM  SQL I  (Modified) 

Repeat 

CALL  Get_SQL_Query (Query ) 

CALL  SQLT ( Query , Request _Stac k , N , Err or s , Request _T ype , 
Format_Opt  i  on  ,  Ar i th_Expr ) 
i f  N  =  0  then  /*■  Syntax  Errors  */ 

CALL  Di spl ay (Query ) 

CALL  Di spl ay (Errors ) 
el  se 

CALL  Request_Control (Request  Stack , N , Request _Type , 

Ari th_Expr ,Resul t_Set ) 

CALL  Di splay (Resul t_Set , FormatOpt i on ) 
end  i  f 

End_of _session? 
unti 1  end_of _sessi on 
end  ALGORITHM  SQLI  (Modified) 


Figure  23.  ALGORITHM  SQLI  (Modified) 


Subroutine  Request _Control <Request_Stack.  ,N, Request  Type, 

Ari th_Expr , Resul t_Set ) 

CASE  Request_Type  OF 

CaseO_Update:  CALL  CaseO_Update <Request_Stack , Resul t_Set ) ; 

Casel_Update:  CALL  Case l_Update ( Request_Stack , Resul t_Set ) ; 

Case2_Update:  CALL  Case2_Update ( Request_Stack , Resul  t  Set )  ; 

Group_Having:  CALL  Group_Havi ng (Request_Stack , 

Condition , Resul t  Set ) ; 

UNION:  CALL  UNION  < Request _Stack. , Resul  t_Set )  ; 

Others:  it  N  =  1  then 


CALL  One_Request (Request_Stack , Resul  t_Set  > 
/*  for  simple,  di recti y— supported  */ 
/*  single  request  */ 

el  se 

CALL  N_Level  Select (Request_Stack , 

N, Resul t_Set) 

end  i  f 


END  CASE 


Figure  24.  Subroutine  Request_Control 
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VIII.  CONCLUDING  REMARKS 


In  this  thesis,  we  have  concentrated  on  the  language 
interface  aspects  of  using  an  attribute-based  database 
system,  MDBS,  as  a  kernel  for  the  support  of  the  relational 
data  model  and  the  relational  query  language,  SOL.  A 
related  thesis  by  Weishar  CRef.  163  provides  the  design  and 
analysis  of  an  interface  for  the  hierarchical  model  and  the 
hierarchical  data  language,  DL/I.  This  work  is  part  of 
ongoing  research  being  conducted  by  the  Laboratory  for 
Database  Systems  Research  under  the  direction  of  Dr.  David 
K.  Hsiao.  As  stated  in  CRef.  ID,  the  goal  of  this  phase  of 
the  laboratory's  research  "...is  to  provide  increased 
utility  in  database  computers.  A  centralized  repository  of 
data  is  made  available  to  multiple,  dissimilar  hosts. 
Furthermore,  the  database  is  also  made  available  to 
transactions  written  in  multiple,  dissimilar  data 
1 anguages. " 

The  rapid  evolution  of  database  technology  has  provided 
the  motivation  for  this  research.  Commercial  database 
management  systems  have  only  been  available  since  the 
1960's.  Today,  organi zati ons  of  all  types  are  critically 
dependent  on  the  operation  of  these  systems.  This 
dependency  comes  from  the  need  to  centrally  control  large 


quantities  of  operational  data.  The  in-formation  must  be 
accurate  and  readily  accessible  by  relatively  inexperienced 
end-users. 

There  are  three  generally  known  approaches  to  the  design 
o-f  database  systems.  These  are  the  network,  hierarchical  , 
relational  approaches.  An  organization  normally  chooses  a 
commercial  system  based  on  one  o-f  these  models.  The 
database  must  be  created  and  operator  and  user  personnel 
must  be  trained.  Because  of  the  re-programmi ng  and  re¬ 
training  effort  (and  money)  required,  an  organization  is 
unlikely  to  change  to  a  system  based  on  one  of  the  other 
model s. 

Me  have  discussed  an  alternative  to  the  development  of 
separate  stand-alone  systems  for  specific  data  models.  In 
this  proposal ,  the  three  generally  known  models  and  their 
model-based  data  languages  are  supported  by  the  attribute- 
based  data  model  and  data  language.  Me  have  shown  (in  the 
relational  case)  how  a  software  interface  can  be  built  for 
such  support. 

Specific  contributions  of  this  thesis  include  extremely 
thorough  explanations  of  SQL  operations  such  as:  set- 
membership,  nested  retrievals,  retrieval  of  grouped 
attributes,  join  operations,  retrieval  of  computed  values, 
providing  format  options,  retrieval  using  UNION,  updating 
multiple  fields,  retrieval  with  ordering,  and  elimination  of 
duplicates.  Me  have  extended  the  work  of  Macy  CRef.  83  by 


showing  that  many  of  the  SQL  constructs  for  the  above 
operations  are  directly  supportable  by  ABDL  and  MDBS. 
Others  can  be  translated  into  a  series  of  the  primary  and 
aggregate  operations  of  the  attribute-based  system.  In  all 
cases,  SQL-to-ABDL  translations  are  provided.  We  have  also 
proposed  a  software  structure  to  facilitate  the  future 
implementation  of  the  SQL  interface. 

A  major  design  goal  has  been  to  design  a  SQL  interface 
to  MDBS  without  requiring  that  changes  be  made  to  the  MDBS 
system.  We  have  shown  that  the  complete  interface  can  be 
implemented  on  a  host  computer.  All  translations  are 
accomplished  in  the  SQL  interface.  MDBS  continues  to 
receive  and  process  requests  written  in  the  syntax  of  ABDL. 
We  have  also  shown  that  the  interface  can  be  designed  to 
utilize  existing  ABDL  constructs  <either  one  or  a  series  of 
ABDL  requests).  No  changes  to  the  ABDL  syntax  are  required. 
We  also  have  not  proposed  any  changes  to  the  syntax  of  SQL. 
We  have  designed  the  interface  to  be  transparent  to  the  SQL 
user.  The  intention  is  that  a  trained  SQL  user  need  know 
nothing  of  the  existence  of  the  interface  or  of  MDBS.  The 
user  can  log  in  at  a  system  terminal,  input  a  SQL  query,  and 
obtain  result  data  in  a  relational  format. 

In  retrospect,  our  unconventional  bottom-up  approach  to 
design  seems  entirely  appropriate.  We  have  built  upon  the 
basic  subset  of  SQL-to-ABDL  mappings  provided  by  Macy  CRef. 
81,  making  additions  to  the  set  as  selected  SQL  operations 


have  been  incorporated  into  the  interface.  As  our 
investigation  begins  in  Chapter  IV,  the  form  of  the 
interface  software  structure  is  not  clear.  When  the  nested 
SQL  SELECT  is  described  in  Chapter  V,  the  requirements  for 
the  structure  begin  to  solidify.  We  become  aware  that  an 
iterative  structure  is  needed  to  control  the  processing  of 
series  of  ABDL  requests.  As  the  algorithm,  SQLI ,  is 
completed  in  Chapter  VI,  it  is  clear  that  we  have  developed 
the  overall  software  structure  for  the  SQL  interface.  The 
functionality  of  the  structure  is  enhanced  as  additional  SQL 
operations  are  selected.  However,  the  general  structure 
remains  intact. 

As  an  alternative  to  implementing  the  SQL  (network  and 
hi erarchi cal ,  as  well)  interface  on  a  host  computer,  the 
interface  can  be  placed  inside  of  MDBS.  We  have  studied 
this  possibility,  and  recommend  against  such  an 
implementation.  A  major  design  goal  of  MDBS  is  to  minimize 
the  role  of  the  controller.  This  goal  can  not  be  attained 
if  the  controller  must  support  the  operation  of  resident 
relational,  network,  and  hierarchical  interfaces. 

We  have  shown  that  the  attribute-based  system  supports 
relational  database  applications.  We  have  provided  SQL-to- 
ABDL  translations  for  selected  database  operations,  and  we 
have  proposed  a  software  structure  to  facilitate 
implementation.  The  next  step  i s  to  implement  the  interface 
on  a  host  computer.  In  order  to  finally  determine  the 


APPENDIX  A:  FORMAL  SPECIFICATION  OF  THE  ATTRIBUTE-BASED 
DATA  LANGUAGE ,  ABDL 

The  following  is  the  BNF  for  the  attribute-based  data 
language  developed  by  Hsiao  and  Menon  CRefs.  4  and  103. 
Square  brackets  C  3  are  used  to  indicate  optional 
constructs. 


Predicate 

:  = 

attribute  rel_op  value 

attr i bute 

:  = 

char_string 

attribute_being_modi f ied 

:  = 

attri bute 

base_attr i bute 

:  = 

attribute 

val  ue 

•  ~ 

string 
!  number 
!  float 

Conjunct 

•  — 

• 

(Predicate) 

!  (Conjunct  /  Predicate) 

Query 

:  = 

Conjunct 

!  Query  /  Conjunct 

Stat 

AVG  !  MAX  !  MIN  !  SUM  i  COUNT 

1  i  st_el 

;  = 

Stat  (attribute) 

list 

" 

attribute 
!  1  i  st  _el 
!  1 i st , attr i bute 

J  list,list_el 

Target_l ist 

:  = 

(list) 

Attrib_val _pair 

:  = 

<attri bute, val ue> 

Hal f _record 

:  = 

Attr i b_val _pai r 
'  Half_record,  Attr i b_val _pai 

Record 


(Half  record) 


Pointer 

Modi f ier 

li  II 

M 

number 
type-O 
!  type-I 
!  type-I I 
!  type-I II 
!  type-IV 

type-0 

:  = 

<attribute_being_modif ied 
val ue> 

type-I 

■ 

<attr ibute-being_modi f ied 
expr 1 > 

type-I I 

■ 

<attr i bute_being_modi f i ed 
expr2> 

type— I I I 

■  — 

<attribute_being_modi-f  ied 
expr2  of  Query/ 

type— IV 

;  = 

<attribute_being_modif ied 
expr 2  of  Pointer > 

Request 

•  — 

• 

Insert  !  Delete  !  Update 
Retrieve 

Insert 

•  - 
■ 

INSERT  Record 

Del ete 

•  — 
a 

DELETE  Query 

Update 

a  — 

UPDATE  Query  Modifier 

Retrieve 

•  — 

• 

RETRIEVE  Query  Target_lis 
CBY  attribute! 

C WITH  Pointer] 

uc-letter 

■ 

A  !  B!  C  !  . . .  iZ 

string 

a 

uc_l  etter 
!  string  uc_l etter 

1 c-1 etter 

S  * ■ 

a  !  b  !  c  !  .  .  .  !  z 

char_string 

a  ^5 

uc_l  etter 

!  char_string  lc_l etter 

digit 

:  = 

0!1!2!3!4!5!  6 
7  18  19 

number 


digit 

■  digit  number 


■f  1  oat 


number . number 


add  _op 
mul t_op 
expr  1 

arith_terml 

ar i th_f actor  1 

expr2 

ar i th_ter m2 

arith  -factor2 


+  :  - 
*  ■  / 

ari th_terml 

!  exprl  add_op  arith_terml 

ari  th_-f  actor  1 
i  arith_terml  mult_op 
ari th_f actor  1 

attr ibutebei ng_modi f i ed 
l  number 

ar i th_term2 

!  expr2  add_op  arith_term2 

ari  th_-f  actor  2 
!  arith_term2  mult_op 
ari th_f actor2 

base_attribute 
•  number 
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